Go back to Market Research
C3 AI sells an enterprise application platform and applications for demand planning, inventory optimization, production scheduling, sourcing, and other industrial functions. Its supply chain software combines enterprise data, generates forecasts and recommendations, and sends selected inventory parameters back to operational systems. The September 2026 compatibility matrix lists Inventory Optimization 5.0, Production Schedule Optimization 6.0, and Demand Planning 3.0 on platform 8.11. (1, 2, 3)
Overall supply chain score: 5.3/10.
| Dimension | Score |
|---|---|
| Supply chain depth | 4.6/10 |
| Decision and optimization substance | 5.6/10 |
| Product and architecture integrity | 5.6/10 |
| Technical transparency | 6.2/10 |
| Vendor seriousness | 4.6/10 |
C3 AI’s strongest evidence is its documented software and inventory research. It models several sources of uncertainty, publishes a substantial programming interface, and provides tools for changing and deploying application logic. Its principal weaknesses are the economic limits of its planning objectives, exaggerated performance claims, and the maintenance burden of a large proprietary platform. The gap between the engineering record and the marketing record is unusually wide.
The inventory application improves an existing MRP workflow by adjusting reorder parameters against costs and service targets. The broader agentic story promises financially grounded, coordinated decisions, but much of the demonstrated workflow still consists of presenting recommendations for planners to assess. C3 Code addresses a more consequential problem: changing the software itself. Its current documentation also identifies migration restrictions and services work that the promise of autonomous application delivery leaves out. (3, 19, 20, 25)
C3 AI versus Lokad
The practical choice concerns what the buyer wants to own and improve. C3 AI provides a general development and operating environment, with supply chain applications among its packaged starting points. A customer can build custom data models, machine-learning pipelines, interfaces, and workflows around its own enterprise systems. This offers considerable scope, together with a continuing obligation to maintain that application estate. (11, 22)
Lokad’s inventory optimization approach centers on the recurring decisions: what to buy, produce, move, or allocate, and their expected economic consequences under uncertainty. The objective is to improve those decisions as a system, including the cost of operating the decision process. The perspective developed in Introduction to Supply Chain matters here because a locally attractive stock reduction can destroy value elsewhere through lost sales, delays, or extra handling.
C3 AI’s inventory software already goes beyond a point demand forecast: supplier timing, delivered quantities, and material movements enter its uncertainty model. The remaining distinction is the decision framework. Meeting a prescribed service target at lower inventory cost leaves the value of that target outside the calculation. A buyer still needs to decide whether scarce cash should protect this item, another item, or a different activity. That economic allocation problem is central to Lokad’s proposition. (3, 4)
C3 Code gives C3 AI a credible route to reducing application development work. The relevant comparison is therefore the sustained effort needed to revise, test, deploy, and monitor the decision logic, including vendor and partner effort. Comparing the number of dashboards, language models, or application templates would miss the operating economics.
Inventory optimization: substantive uncertainty, restricted economics
C3 AI’s February 2025 paper describes simulation-based optimization of MRP reorder settings. It samples empirical distributions for demand error, material movements, supplier quantities, and supplier timing. It pools suppliers’ behavior for each SKU when supplier-specific observations are insufficient. Its objective includes holding, ordering, and transport costs under a service constraint. (4)
This is more substantive than attaching an uncertainty band to a demand forecast. It also exposes a material weakness: two suppliers with different reliability can disappear into one pooled distribution. Better sampling cannot recover a distinction removed from the model. Nor does replaying many possible futures establish that shared cash, capacity, and complementary parts are valued together. These are questions about the representation of the business, before questions about computational speed.
The November 2025 data sheet separately claims assortment optimization across facilities and multi-echelon optimization across a bill of materials. It supports manual or automatic approval and writes revised parameters into MRP. How those network objectives and dependencies combine with the published SKU-level mechanism remains unexplained. A shared data image can connect the inputs while the economic calculations remain separate. (3)
The paper’s results also require careful reading. Its comparison table mixes inventory and safety-stock measures and compares historical operations with simulated alternatives. One customer’s service level falls from 97.6% to 91.0% while inventory falls from $7.7 million to $6.5 million. The commercial meaning depends on the cost of that lost service, not just the inventory reduction. (4)
This is the issue developed in Holimization: the formulation itself requires continual correction. A cheaper buffer policy may be a useful improvement. Calling it optimal does not establish that the omitted choices and consequences are economically negligible.
Forecasting claims and digital twins
The current Demand Planning page advertises overall forecast accuracy above 92%, alongside forecasting at every granularity and time horizon. It does not attach a metric, horizon, aggregation level, or evaluation population to that headline. It also promotes a case with a 100% reduction in forecasting error. These are consequential omissions in a purchasing claim, because aggregation and the choice of baseline can dominate the apparent result. (5)
The underlying high-tech case concerns an initial division with 900 SKUs. It reports a 70–100% reduction in WAPE against previous forecasts, including a competing model with WAPE above 200%. It identifies a 6–7% potential inventory reduction and $300 million in savings at full company scale. It provides neither the final error distribution at the replenishment horizon nor the test design needed to assess the 100% endpoint. The financial number is an extrapolated opportunity. (6)
A relative reduction from a poor baseline is not an absolute accuracy score. Even a genuine improvement at a sales-planning level cannot be transferred to item-level buying decisions without the relevant horizon and aggregation. As a quantitative reference, a diagnostic using the M5 competition’s top 50 point-forecast submissions gives roughly 22–25% for 100 × (1 − WAPE) at SKU/store/day, versus roughly 96–98% after pooling products and stores by day. These are diagnostic transformations, not the competition’s official score or a universal ceiling. They show how little an isolated percentage tells a buyer. (33)
C3 AI’s demand page describes its digital twin as a unified supply chain data foundation. Its scheduling page uses the same term for a representation of production operations. Data integration can be valuable, but forecasting the consequences of an intervention is a further task. The published material needs to show whether predicted shortages, production gains, and financial effects survive comparison with subsequent operations. Feature explanations and an interactive scenario screen do not establish that accuracy. (5, 10)
Scheduling, productivity, and economic evidence
The steel case is informative because it describes the work behind the result. Over 26 weeks, a joint team encoded mill-specific constraints and connected historical operational data. The optimizer was evaluated against 46 historical production cycles. C3 AI reports about 1% more net production and scheduling reduced from five to seven days to one hour; the $4 million headline is potential annual benefit across three mills. (9)
Codifying transition rules, yields, and material reuse is substantial engineering work. Historical replay helps assess a model, but additional output has value only when it can be sold profitably and delivered without displacing more valuable work. The published case leaves the cost of maintaining those rules, reviewing generated schedules, and correcting operational mismatches unquantified. Faster schedule generation is a useful productivity result; it is only one component of the recurring workload.
Another case concerns one agribusiness plant with eight lines. It specifies daily forecasts 21 days ahead and schedules by shift over a rolling 14 days, reports 96% less scheduling effort, and identifies $30 million of additional gross margin. The workflow still asks users to assess recommendations and tune scenario inputs. The stated horizon makes this evidence more useful than the generic accuracy headline, while the identified margin remains distinct from a measured net return. (34)
The electronics inventory case reports $42 million of working-capital reduction for 10,000 in-scope SKUs. Its adoption evidence is that managers accepted 74% of recommendations during testing and review. That measures acceptance, not correctness or autonomous coverage. Working capital released is also different from recurring annual profit: its financial value must be assessed alongside stockout consequences, carrying costs, and the expense of the software and operating team. (7)
The aerospace case labels $180–240 million as potential inventory-reduction value following a ten-week trial. It also reports 80% accuracy predicting supplier delays or de-commitments without the event prevalence or false-positive cost. Predicting disruption and deciding how much to spend protecting against it are different problems. The case does not supply enough information to price that trade-off. (8)
Across these examples, C3 AI reports identifiable operational work and potentially valuable improvements. The missing common denominator is a sustained, fully costed outcome: realized margin and capital effects, remaining planner effort, maintenance services, and the remedy when results miss the agreed baseline.
Agentic operations and configuration maintenance
The March 2026 supply chain essay correctly criticizes local KPIs that degrade the whole system. Its proposed agent workflow nevertheless centers on helping a planner diagnose disruption, compare responses, and act. Current Agentix documentation is more explicit: the embedded assistant reads connected data, while a change to a record waits for user approval. That is an assisted workflow. Requiring a conversation around every routine action would preserve the labor bottleneck at greater scale. (24, 25)
C3 Code addresses a different workload. Its release notes document editable application modules, Git integration, parallel chats, and scheduled deployment pipelines. These features can help a team improve reusable logic rather than repeatedly process the same exceptions. The central MCP documentation also includes tools that edit Types and generate transforms; this particular connector supports development work. The protocol itself adds no supply chain intelligence, and its presence earns no optimization credit. (22, 23)
There are material boundaries to the promise. The FAQ says older SDL-based Inventory Optimization and Production Schedule Optimization applications cannot be extended until they move to React-based versions. Deployment documentation says customer-cluster delivery and platform upgrades happen outside C3 Code and usually involve the C3 AI services team. Buying an existing application therefore does not automatically deliver the maintenance productivity advertised for a new coding workspace. (19, 20)
The deployment mechanics are usefully explicit. Staging and production have stamped versions; a scheduled pipeline deploys a Git branch, while manual deployment can include changes not committed to GitHub. Returning to earlier code requires another deployment. Buyers need a tested recovery process for both logic and data, plus a clear owner for upgrades and compatibility work. Code generation can lower the cost of a change while leaving validation, data migration, and operational recovery as substantial expenses. (20, 21)
Software bill of materials and ownership cost
C3 AI has a coherent architectural center: its Type System defines data structures, relationships, and methods behind a common programming interface. That reduces duplicated integration work inside the platform. It also makes the runtime a substantial dependency: exporting Python or JavaScript files is not sufficient to reproduce the services those files invoke. The launch claim of no technical lock-in is broader than the documented ability to switch language models. (11, 30)
The platform’s 8.11 restricted-egress deployment guide identifies Terraform, Helm, C3 AI servers, Jupyter, Cassandra, and Postgres. It also describes local mirrors for Python and Node.js packages. These are actual deployment components with separate upgrade, backup, monitoring, and recovery obligations. (13)
The employer’s Platform Data and AI engineering vacancy reinforces the breadth of the integration work. Its responsibilities include abstractions over Cassandra, PostgreSQL, and Snowflake; storage interfaces; distributed processing; and integrations with Spark and Ray. Snowflake is an integration target in that description, not evidence that every inventory installation runs it. The job explains the engineering burden of supporting a broad platform across customer environments. (12)
Managed Jupyter allocates dedicated per-user compute, while runtime definitions specify Python packages and versions. That is useful operational structure, with costs that extend beyond the planning algorithm: notebook infrastructure, dependency resolution, test environments, retained application versions, and the staff maintaining them. A platform spanning many use cases can share those costs. A buyer seeking only inventory decisions should require that the proposed deployment justifies its entire footprint. (14, 16)
Security of practitioner code
C3 AI explicitly supports arbitrary Python methods and libraries obtained through public or private Conda channels. Managed notebooks authenticate users to the application and expose its data and services. This puts dependency trust and production-data privileges at the center of the security assessment. A user-friendly notebook does not make package installation or generated code safe. (14, 15)
There are documented mechanisms: per-user notebook containers, configurable resources, restricted-egress deployment, and local package repositories. The October 2026 patch notes also expose JupyterHub egress-policy configuration. These give operators controls to work with. The public account still needs to establish the default network boundary, package approval policy, and least privileges available to each practitioner in the production deployment. (13, 14, 17)
The same patch notes record fixes for group-membership methods that previously authorized calls without enforcing the caller’s permissions, and for cloud credential lookups that could run custom overrides with elevated privileges. These are concrete access-control defects, documented as fixed in 8.11.7. Their relevance is the importance of the actual patch level and privilege design, rather than a certification badge. Public disclosure of the fixes is useful evidence of maintenance. (17)
One troubleshooting procedure advises deleting a Kubernetes network policy when it interferes with Jupyter communication, without a restoration step in that procedure. Removing an isolation control to get the service running is weak operational guidance. A production design should preserve the intended boundary through diagnosis and recovery, especially when non-specialists can execute general-purpose code against business data. (18)
Technology history and roadmap integrity
C3 AI’s own history dates its first energy-management product to 2010, the C3 Energy period to 2013–2015, C3 IoT to 2016–2018, and the C3 AI name to 2019. It explains the changes as market expansion and changing perceptions of IoT. This establishes a pattern of positioning around successive technology markets, while also identifying continuing applications and a common platform. (26)
The February 2016 IoT release already promoted a complete platform, machine learning, rapid application development, and production pilots in as little as a month. Its stated installed base was 70 million meters and sensors across 20 deployments. Those were data-processing and predictive-analytics claims from the pre-LLM period. They should be assessed against those tasks, not retrospectively credited with the capabilities of today’s agents. (27)
Baker Hughes provides a continuity check. Its account describes internal developers and data scientists configuring the inventory application from late 2019, with an expected inventory reduction of about 5% at deployed locations. In May 2025, the companies renewed their collaboration through June 2028 and explicitly included further internal inventory deployments. This is a sustained partnership with identifiable software work; the early forecast of savings remains an expectation in that historical account. (28, 32)
The January 2023 generative-AI announcement proposed enterprise search using external models, with general availability planned for March. The delivered category was access to enterprise information through natural language. The subsequent agentic claims broadened toward workflows and application generation. The engineering question is how much of the underlying work those releases remove, beyond making existing functions easier to call. (29)
The April 2026 C3 Code launch illustrates the marketing problem sharply. C3 AI presented a superiority table based on Claude reading product documentation, giving its own product 9.2/10 against 6.0 for Codex and 5.2 for Claude Code. This was not a comparative application-building experiment. An LLM’s rating of promotional material supplies no measurement of deployment success, maintenance effort, or security. Presenting it as competitive performance weakens the credibility of the broader productivity claims. (30)
The release documentation establishes continuing engineering work through implemented development workflows, compatibility restrictions, and detailed fixes. The announcements repeatedly elevate that work into claims far broader than the measured results.
C3 AI’s September 2026 results also update the corporate picture: Thomas Siebel was again chairman and CEO, quarterly revenue was $52.4 million, and cash and marketable securities totaled $651.1 million during a restructuring. The company has financial resources; customers committing to its runtime still need continuity arrangements for application support and upgrades as the organization changes. (31)
Supply chain score
The overall score is the simple average of the 25 criteria below. Each dimension averages its five criteria; the overall result is 5.32, rounded to 5.3/10.
Supply chain depth
| Criterion | Score |
|---|---|
| Economic framing | 5/10 |
| Decision end-state | 6/10 |
| Conceptual sharpness on supply chain | 6/10 |
| Freedom from obsolete doctrinal centerpieces | 3/10 |
| Robustness against KPI theater | 3/10 |
Average: 4.6/10.
Economic framing — 5/10. Inventory costs, working capital, and production value have identifiable roles. Prescribed service levels still substitute for valuing the complete consequences of shortages and competing uses of resources. Reported financial opportunities are often easier to find than realized net returns. (3, 7, 9)
Decision end-state — 6/10. The inventory application writes parameters into MRP, with automatic approval available. Scheduling produces executable planning inputs. Much of the broader agentic workflow still ends with a person inspecting recommendations, leaving the volume of unattended decisions unclear. (3, 24, 34)
Conceptual sharpness on supply chain — 6/10. C3 AI recognizes supply uncertainty, material dependencies, and the damage caused by local optimization. The inventory research and mill-specific modeling show more understanding than a generic forecasting pitch. Connecting these mechanisms into a consistent economic decision system remains insufficiently demonstrated. (4, 9, 25)
Freedom from obsolete doctrinal centerpieces — 3/10. Service targets, safety-stock parameters, consensus demand plans, and planner approval retain central roles. The software improves these processes substantially without resolving the limitations of the underlying targets and organizational routines. (3, 5, 24)
Robustness against KPI theater — 3/10. Unqualified overall accuracy, a headline reaching zero forecast error, and full capacity utilization are poor substitutes for defined economic outcomes. Several case studies identify useful scope, but their discipline does not carry through to the product headlines. (5, 6, 10)
Decision and optimization substance
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 6/10 |
| Distinctive optimization or ML substance | 6/10 |
| Real-world constraint handling | 6/10 |
| Decision automation and labor productivity | 5/10 |
| Resilience under real operational complexity | 5/10 |
Average: 5.6/10.
Probabilistic modeling depth — 6/10. The published inventory mechanism models several operational uncertainties together. Its pooling choices lose relevant distinctions, and the treatment of dependencies across suppliers, items, and shared resources needs greater substantiation. (4)
Distinctive optimization or ML substance — 6/10. Inspectable inventory research and specific forecasting and scheduling implementations support genuine engineering credit. The contribution lies in the model and integration work, rather than the AI label or the use of repeated simulations. (4, 9, 34)
Real-world constraint handling — 6/10. Bill-of-materials handling and the steel case’s transition and yield rules show attention to physical operations. The published evidence is less complete on whether economic interactions survive when the scope expands beyond the individual application. (3, 9)
Decision automation and labor productivity — 5/10. Schedule-generation savings and automated parameter updates are useful. C3 Code offers a further route to reducing configuration work. Remaining reviews, application migrations, and services effort prevent translating those benefits directly into an equivalent reduction in total operating labor. (3, 9, 19, 20)
Resilience under real operational complexity — 5/10. Historical testing and real data integrations provide a basis for operation. More evidence is needed on economic performance after structural changes, including new suppliers, changing product relationships, and corrections to the model itself. A continuously refreshed input is not necessarily a corrected formulation. (9, 34)
Product and architecture integrity
| Criterion | Score |
|---|---|
| Architectural coherence | 7/10 |
| System-boundary clarity | 7/10 |
| Security seriousness | 4/10 |
| Software parsimony and ownership cost | 3/10 |
| Compatibility with programmatic and agent-assisted operations | 7/10 |
Average: 5.6/10.
Architectural coherence — 7/10. The Type System provides a substantive common foundation across data, code, and applications. The SDL-to-React transition limits continuity for existing applications and creates migration work inside that otherwise coherent architecture. (11, 19)
System-boundary clarity — 7/10. Documentation distinguishes application versions, notebook instances, deployment environments, and services work outside C3 Code. These boundaries are considerably more inspectable than the broad autonomous-platform positioning suggests. (1, 14, 20)
Security seriousness — 4/10. Isolation controls and explicit privilege fixes provide concrete evidence. Practitioner Python remains a demanding trust boundary, while the network-policy troubleshooting advice is weak. Buyers need verified production restrictions and patch state; general governance claims cannot answer those questions. (15, 17, 18)
Software parsimony and ownership cost — 3/10. The deployment combines multiple data services, runtime ecosystems, and infrastructure tools. Supporting diverse use cases explains much of that mass, but the inventory buyer still bears its cost through hosting, platform operations, upgrades, and specialist services. (12, 13, 20)
Compatibility with programmatic and agent-assisted operations — 7/10. APIs, source-controlled application artifacts, code-generating agents, and scheduled deployment are meaningful capabilities. Their value is in improving repeatable logic. MCP access and conversational approval alone do not provide autonomous supply chain optimization. (22, 23, 24)
Technical transparency
| Criterion | Score |
|---|---|
| Public technical documentation | 8/10 |
| Inspectability without vendor mediation | 6/10 |
| Portability and lock-in visibility | 5/10 |
| Implementation-method transparency | 6/10 |
| Evidence density behind technical claims | 6/10 |
Average: 6.2/10.
Public technical documentation — 8/10. The developer documentation, version matrix, release notes, and inventory paper contain enough detail to identify mechanisms and limitations. This is a substantial public engineering record. (1, 4, 17)
Inspectability without vendor mediation — 6/10. Much of the platform can be assessed from public documentation. Application behavior is less exposed than platform mechanics, and published commercial examples do not include reproducible customer datasets or decision traces. (1, 6, 7)
Portability and lock-in visibility — 5/10. Git access and language-model choice help preserve application work. Applications still depend on proprietary Types and platform services, and deployment outside the managed workflow involves additional work. The public no-lock-in claim understates that dependency. (11, 20, 30)
Implementation-method transparency — 6/10. Cases describe data integration, configuration, and implementation duration; deployment guides expose meaningful operational steps. They reveal less about sustained maintenance budgets and the division of responsibility when an application’s economic performance deteriorates. (9, 20, 34)
Evidence density behind technical claims — 6/10. The research and documentation are unusually useful. Anonymous cases, extrapolated financial benefits, and missing forecast-test definitions weaken the connection between that technical substance and the advertised business results. (4, 6, 8)
Vendor seriousness
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 3/10 |
| Technology roadmap integrity | 5/10 |
| Conceptual sharpness | 5/10 |
| Economic accountability | 4/10 |
| Defensibility in an agentic-software world | 6/10 |
Average: 4.6/10.
Technical seriousness of public communication — 3/10. Using an LLM’s reading of product documentation as evidence of competitive superiority is particularly weak. Unqualified forecasting headlines compound the problem. These choices damage the credibility earned by the engineering documentation. (5, 30)
Technology roadmap integrity — 5/10. Applications, a common runtime, and the Baker Hughes relationship persist through successive branding phases. Current code-generation features have documented implementations. Repeatedly announcing transformative capabilities before establishing their operational boundaries prevents a stronger score. (19, 26, 32)
Conceptual sharpness — 5/10. The critique of fragmented decisions and the focus on application-development work are sound. Marketing repeatedly compresses different achievements—data access, forecasting, recommendation, code generation, and economic optimization—into the same broad AI promise. (22, 25, 30)
Economic accountability — 4/10. Some cases disclose scope and distinguish potential benefits. The public record rarely connects realized financial outcomes to all implementation, review, cloud, and maintenance costs, with an agreed procedure for correcting failed economics. Acceptance and user trust do not close that gap. (7, 8, 9)
Defensibility in an agentic-software world — 6/10. A documented domain platform and tools for revising applications can retain value as code generation becomes cheaper. Defensibility depends on preserving useful operational knowledge while reducing the cost of maintaining it. Runtime complexity and legacy migration work weigh against that opportunity. (19, 20, 22)
Sources
[1] Application compatibility, September 2026
Application compatibility, September 2026. 2026-09-11; Accessed November 4, 2026. [2] Inventory Optimization product
Inventory Optimization product. Accessed November 4, 2026. [3] Inventory Optimization data sheet
Inventory Optimization data sheet. 2025-11-17; Accessed November 4, 2026. [4] Stochastic Optimization of Inventory at Large-scale Supply Chains
Stochastic Optimization of Inventory at Large-scale Supply Chains. 2025-02-16; Accessed November 4, 2026. [5] Demand Planning product
Demand Planning product. Accessed November 4, 2026. [6] High-tech forecasting case
High-tech forecasting case. Accessed November 4, 2026. [7] Electronics inventory case
Electronics inventory case. Accessed November 4, 2026. [8] Aerospace inventory trial
Aerospace inventory trial. Accessed November 4, 2026. [9] Steel production scheduling case
Steel production scheduling case. Accessed November 4, 2026. [10] Production Schedule Optimization product
Production Schedule Optimization product. Accessed November 4, 2026. [11] Type System overview, platform 8.11
Type System overview, platform 8.11. Accessed November 4, 2026. [12] Senior Software Engineer, Platform Data and AI, job 8365468002
Senior Software Engineer, Platform Data and AI, job 8365468002. Accessed November 4, 2026. [13] Restricted-egress deployment, platform 8.11
Restricted-egress deployment, platform 8.11. Accessed November 4, 2026. [14] Managed JupyterLab, platform 8.11
Managed JupyterLab, platform 8.11. Accessed November 4, 2026. [15] Python access, platform 8.11
Python access, platform 8.11. Accessed November 4, 2026. [16] Python runtimes, platform 8.11
Python runtimes, platform 8.11. Accessed November 4, 2026. [17] Platform 8.11 patch notes
Platform 8.11 patch notes. 2026-10-28; Accessed November 4, 2026. [18] Jupyter troubleshooting, platform 8.11
Jupyter troubleshooting, platform 8.11. Accessed November 4, 2026. [19] C3 Code FAQ, platform 8.11
C3 Code FAQ, platform 8.11. Accessed November 4, 2026. [20] Deploy Your Application, C3 Code
Deploy Your Application, C3 Code. Accessed November 4, 2026. [21] Manage Your Deployments, C3 Code
Manage Your Deployments, C3 Code. Accessed November 4, 2026. [22] C3 Code release notes
C3 Code release notes. Accessed November 4, 2026. [23] C3 Central MCP Server configuration
C3 Central MCP Server configuration. Accessed November 4, 2026. [24] Add an Agentix Agent to Your Application
Add an Agentix Agent to Your Application. Accessed November 4, 2026. [25] From Static Plans to Intelligent Action
From Static Plans to Intelligent Action. 2026-03-20; Accessed November 4, 2026. [26] The Evolution of C3 AI
The Evolution of C3 AI. 2023; Accessed November 4, 2026. [27] Full-Stack IoT Development Platform release
Full-Stack IoT Development Platform release. 2016-02-23; Accessed November 4, 2026. [28] Baker Hughes: Enterprise AI for Inventory Optimization
Baker Hughes: Enterprise AI for Inventory Optimization. Accessed November 4, 2026. [29] Generative AI Product Suite announcement
Generative AI Product Suite announcement. 2023-01-31; Accessed November 4, 2026. [30] C3 Code general availability announcement
C3 Code general availability announcement. 2026-04-08; Accessed November 4, 2026. [31] Fiscal first quarter 2027 results
Fiscal first quarter 2027 results. 2026-09-02; Accessed November 4, 2026. [32] Baker Hughes joint venture renewal
Baker Hughes joint venture renewal. 2025-05-28; Accessed November 4, 2026. [33] M5 competition methods, pinned revision
M5 competition methods, pinned revision. Accessed November 4, 2026. [34] Agribusiness demand and scheduling case
Agribusiness demand and scheduling case. Accessed November 4, 2026.