Go back to Market Research
ketteQ supplies cloud software for demand, inventory, production, service-parts, and fulfillment planning. Its PolymatiQ engines evaluate planning scenarios, while Quintus provides a conversational interface and agents that can perform tasks across planning and execution systems. Customers can deploy the software alongside an existing planning platform or use ketteQ’s own applications; Salesforce integration is optional in the current architecture. (1, 2)
Overall supply chain score: 4.0/10
| Dimension | Score |
|---|---|
| Supply chain depth | 4.4/10 |
| Decision and optimization substance | 5.0/10 |
| Product and architecture integrity | 4.0/10 |
| Technical transparency | 3.2/10 |
| Vendor seriousness | 3.6/10 |
ketteQ has substantial application breadth and named customers reporting operational improvements. The stronger technical claims are poorly bounded: the company promises arbitrary supply chain reasoning, automatic changes to decision logic, and optimal answers in seconds without publishing the underlying optimization formulation or its validation. Generated Python connected to operational systems makes the missing execution boundaries particularly consequential. Faster answers and a long list of scenarios do not establish reliable economic decisions. (2, 3, 10)
The most credible evidence is narrower and more useful: production planning at Partner in Pet Food, differentiated demand treatment at quip, and fast order promises at Alliance Consumer Group. These cases show working software. They also expose the distance between an implemented planning application and a universally capable autonomous supply chain system. (10, 11, 12)
ketteQ versus Lokad
ketteQ adds planning capabilities to an existing enterprise environment, including sales and operations workflows in Salesforce. Its applications package familiar planning objects and workflows; Quintus extends how users interrogate and operate them. Lokad’s inventory optimization service organizes the work around recurring decisions and their financial consequences under uncertainty.
That difference becomes material when service targets, capacity utilization, working capital, and commercial commitments conflict. A planning engine needs an economic rule for choosing between them. A conversation about those trade-offs does not supply the rule, and generating more candidate plans does not establish which one creates the most value. ketteQ publishes much more about exploring scenarios and adjusting parameters than about the deployed objective that ranks competing actions. (5, 8, 9)
Lokad’s Supply Chain Scientists build, operate, and maintain the decision logic. Their work includes revising the economics when an apparently sensible recommendation proves costly. For example, an expedited spare may protect uptime while consuming the budget needed for several more valuable repairs. The calculation must compare those consequences. Introduction to Supply Chain develops the perspective behind that operating model; its performance depends on realized returns after all maintenance and operating labor.
What PolymatiQ actually establishes
Scenarios need probabilities and economic meaning
ketteQ explicitly recognizes both demand variability and uncertain lead times. Its February 2026 account of the planning engine says it evaluates these alongside service targets, materials, production capacity, stockout penalties, and financial objectives. The product is therefore aiming beyond point-demand forecasting with fixed supply assumptions. (8, 9)
The missing detail is how those quantities become a coherent joint model. Public descriptions do not disclose how scenario probabilities are estimated, how dependencies between demand and supply are represented, or how tail events influence the chosen action. A collection of plausible futures is not yet a calibrated probability distribution. Running a thousand variants can repeatedly explore the wrong assumptions while missing a rare, expensive event.
Current product pages describe forecast ranges, inventory buffers, order-policy tuning, multi-echelon allocation under a budget, and constrained production planning. These are relevant functions, but they do not reveal the computational method behind PolymatiQ. No identifiable solver formulation, reproducible decision benchmark, or public technical reference establishes the advertised universal optimum. (4, 5, 6)
The first issue is not whether the solver finishes quickly enough. It is whether the model values the right consequences. A plan can satisfy every encoded constraint while accumulating obsolete inventory, making an expensive service promise, or consuming scarce capacity on the wrong product. Speed amplifies a flawed decision rule as readily as a good one. The advertised ability to rewrite logic makes testing the changing formulation more important, not less.
Service parts reveal genuine depth and conventional foundations
The service-parts page covers installed equipment, failure rates, returns, repair flows, scrapping, rotable pools, part substitution chains, and alternatives such as buying, repairing, rebalancing, or recovering parts. These details place ketteQ well inside the supply chain software category. It also explicitly lists reorder-point and economic-order-quantity policies, configurable stocking-list criteria, and service-level buffers. (7)
That combination is revealing. The operational coverage is substantial, while the decision framework retains conventional policy parameters beneath the autonomous branding. Automatically tuning a reorder point does not establish that reorder-point logic adequately captures irregular demand, repair uncertainty, shared spares, and asymmetric downtime costs. A sophisticated interface can preserve the same restrictive model underneath.
The inventory application also retains consensus approval and allows users to select among strategies. Such controls can serve a legitimate role, but they leave open how much routine selection remains with planners. End-to-end autonomy should be assessed through the proportion and value of decisions executed successfully without intervention, not through the number of agents or scenarios. (5)
Customer results and economic accountability
Partner in Pet Food: a useful deployment, a projected financial return
Partner in Pet Food retained Kinaxis and added PolymatiQ. ketteQ reports that its team used existing Kinaxis expertise to integrate with the customer’s workflows, with the first plant live in six weeks. The initial planning cycle produced a reported 13% increase in capacity utilization and $8 million in projected annual savings, followed by a wider European rollout. (10)
The case supports successful augmentation of an incumbent application. It does not establish that Kinaxis had reached a fundamental mathematical limit, as the surrounding narrative suggests. Different modeling choices, application scope, data treatment, and implementation work can all improve a production plan. The publication does not isolate those contributions from the new solver’s computation.
The financial claim also remains a projection. Increased utilization creates value only when the additional output is worth producing after demand, inventory, labor, and other costs are considered. The case provides no reconciliation between its annual estimate and realized margin. This matters because the current Quintus FAQ closes its customer discussion by describing results categorically as real rather than projected, while elsewhere repeating the projected savings figure. (3, 10)
Alliance Consumer Group: planning connected to sales
The ACG case describes more than 200 sales representatives obtaining available-to-promise answers through Salesforce. It reports inventory turns increasing from roughly 2.6 to 3.75, with seasonal peaks around 4.1, a $2–5 million year-over-year inventory reduction, and OTIF moving from the 60s or 70s into the high 90s. Read-only sales access also reduced requests to planners. (11)
This is a practical productivity mechanism: answering a recurring question directly can remove an entire exchange between teams. The service percentage is a delivery measure, not forecast accuracy. The inventory reduction releases capital; it is not automatically an equal amount of annual profit. The case lacks the observation windows, demand normalization, and cost accounting needed to turn those operational changes into a comparable net return.
quip and MobilityWorks: useful specificity, incomplete accounting
At quip, ketteQ separated subscription demand, approximately 20% of the total, from other sales. The case reports a $17 million inventory reduction and a 150% productivity increase with fewer planners. Separating committed recurring demand from uncertain new purchases is a substantive modeling improvement. The publication does not provide the workload denominator, planner counts, or continuing vendor effort behind the productivity percentage. (12)
The MobilityWorks account connects inventory decisions with higher interest rates and falling demand. It reports a $4.7 million reduction in inventory cost over six months and fewer daily stocking alerts over a year. This gives a concrete economic reason to change inventory policy. The page alternates between inventory-cost and savings language without an accounting bridge, and its summary and results sections give different fill-rate improvements. Those limits prevent treating the headline as a precise financial benchmark. (13)
Together, these cases support usable planning applications and operational benefits. They do not isolate the later Quintus functionality from the earlier planning deployments, quantify all implementation and maintenance labor, or show how unsuccessful recommendations are attributed and corrected. A named testimonial is valuable; it does not resolve those questions.
Productivity, configuration maintenance, and ownership cost
The current homepage says that additional use cases require no services engagement. The more concrete AI Studio description, published in June 2026, presents a substantial development process: prototypes in two to three weeks, customer-data validation over four to six weeks, then engineering hardening, with an approximately five-month path to production. Partners contribute expertise and delivery; ketteQ supplies development and shares revenue. (14, 24)
The marketing does not define which new use cases need no services and which require months of product engineering. That boundary determines who can change the system, the cost of each change, and who maintains the resulting logic as data and operations evolve.
The Business Architect vacancy confirms the workload: translating requirements, designing integrations and data flows, testing, adoption, training, go-live, and resolving implementation issues. These responsibilities need to appear in the cost of deployment and subsequent changes. (16)
AI Studio provides a useful automation example: a live demonstration processed 24 of 29 emergency orders overnight and surfaced the remaining five for attention. That is a much more meaningful unit of productivity than scenario throughput. It is still a demonstration, with no sustained production workload or failure-cost record. (14)
The long-term task is maintaining the decision model. Changing a parameter after a disruption differs from discovering that the model omitted a cost, substitution, or operational restriction. The latter requires reformulation and tests showing that the new decisions improve outcomes. This is the holimization problem. ketteQ’s development process offers a place to perform that work, but its public description does not show an economic regression test or a production example of such a correction.
A human-guided AI article published by ketteQ recognizes that incomplete objectives produce poor outcomes and that priorities must be revised over time. It also recommends separating exploration from execution. Those are sound concerns. They sit uneasily beside the newer promise of unconstrained, unconfigured action and automatic rewiring of logic. The unresolved issue is the operating contract: which decisions are pre-authorized, which changes require validation, and whose work is included in the claimed automation. (3, 15)
Bill of software materials and execution security
| Evidence and scope | Documented materials | Consequence |
|---|---|---|
| Current platform description | Relational database, embedded Python, JSON/Java | A recognizable application architecture, with proprietary planning behavior still hidden behind product interfaces. |
| Current platform description | AWS Bedrock for exchangeable language models | Model hosting supplies one layer; application permissions and code execution remain separate responsibilities. |
| Current Salesforce integration | Optional managed-package access and single sign-on | Existing Salesforce workflows can be reused, while the integration boundary still needs operating ownership. |
| Business Architect vacancy | SQL, including PostgreSQL, JSON, XML, and Python familiarity | Hiring supports a data-and-integration workload; it does not identify every production database. |
| Quintus launch | Python generated and executed dynamically | Code containment and restricted production privileges become central design requirements. |
Adding a decision layer above an existing planner creates an ownership cost of its own. Customers retain the old platform while adding data mappings, permissions, operational dependencies, and another place where planning logic can change. A short deployment does not remove the recurring cost of keeping those systems consistent.
The most serious architectural omission concerns generated code. Quintus’s launch explicitly describes Python created and executed on demand. The governance explanation emphasizes auditability, explanations, and human override. The earlier agents page adds encryption, access controls, and tenant isolation claims. None of these sources specifies the execution sandbox, permitted network destinations, filesystem access, dependency controls, resource limits, or the production-data privileges granted to generated programs. (2, 3, 25)
An audit trail records an action after it occurs; it does not prevent data exfiltration or an unauthorized write. A plausible natural-language explanation does not prove that the executed code respected its intended permissions. Human override also cannot undo every external effect. For a product whose distinguishing feature is dynamically executable logic across enterprise systems, the missing boundary is a major weakness in the public technical proposition. Hosting credentials and compliance badges do not answer it.
Programmatic operation is promising, but inspectability remains limited. The platform mentions agent-to-agent integration and ordinary enterprise connections. The reviewed material provides no public SDK, detailed execution API, or runnable example through which a buyer could inspect and independently test the full planning behavior. (1)
Historical promises and follow-through
| Period | Public development | What the record establishes |
|---|---|---|
| 2021–2022 | AI-powered demand and replenishment; Salesforce/AWS platform | Early AI language accompanied planning and visibility claims, without a disclosed autonomous reasoning mechanism. The 2022 leadership announcement identifies the cloud platform and existing deployments. |
| 2023 | ChatGPT enthusiasm | A company article relied partly on ChatGPT’s description of its own future supply chain applications. This was speculation, not evidence of a delivered product. |
| 2024 | Tokyo release and PolymatiQ | Automatic scenario testing, parameter adjustment, economic indicators, and a conversational interface became explicit product features. |
| 2025 | Dubai release and new funding | The release added two-stage production planning, allocation strategies, and performance reporting. The $20 million Series B also funded delivery, customer success, and partner capacity. |
| February–June 2026 | Digital agents, human-guided design, AI Studio | General availability was announced, while technical and delivery articles described guardrails, validation, and production hardening. |
| August 2026 onward | Quintus and Free-Range AI | The company launched broader autonomous reasoning and generated-code claims, alongside assertions that its architecture had anticipated this behavior since 2019. |
Sources: 2, 14, 15, 17, 18, 19, 20, 21, 22, 23.
The historical weakness is retrospective inflation: the current FAQ claims seven years of production operation for capabilities that competitors still put on roadmaps. The dated releases document distinct additions over time. A platform’s origin cannot establish the maturity of its newest functionality. (3, 19, 20)
The same inflation affects the breadth of the promise. PolymatiQ’s technical method remains undisclosed while the language progresses from planning assistance to the sole architecture capable of arbitrary real-time decisions. A trademarked category defined around one’s own product is not a technical benchmark. The evidence should establish what works, under which constraints, and with what failure rate.
Economic accountability is also weakly specified. The 2025 funding announcement claims a 100% implementation success rate without defining the population, acceptance criterion, or economic threshold. AI Studio argues that model quality is almost never the cause of failed AI initiatives and focuses on foundations instead. Data and integration failures are real, but model adequacy cannot be excluded in advance. Otherwise, technical success can be declared while disappointing economics are attributed indefinitely to deployment conditions. (14, 22)
Supply chain score
Each dimension averages five criteria on a 0–10 scale. The overall score is the mean of all 25.
Supply chain depth
| Criterion | Score |
|---|---|
| Economic framing | 5/10 |
| Decision end-state | 6/10 |
| Conceptual sharpness on supply chain | 5/10 |
| Freedom from obsolete doctrinal centerpieces | 3/10 |
| Robustness against KPI theater | 3/10 |
Average: 4.4/10.
Economic framing — 5/10. Customer accounts identify capital, waste, and operating-cost concerns. They do not show the common economic objective through which competing decisions are ranked. (10, 13)
Decision end-state — 6/10. Order promises, production plans, and replenishment recommendations reach operational decisions. The measured results leave their acceptance and execution boundaries only partly visible. (10, 11)
Conceptual sharpness on supply chain — 5/10. Repair flows and production dependencies show domain knowledge. The universal reasoning promise is less precise than the underlying application descriptions. (6, 7)
Freedom from obsolete doctrinal centerpieces — 3/10. Familiar stocking policies, buffers, and consensus processes remain prominent. Automatic tuning does not establish that their underlying simplifications have been overcome. (5, 7)
Robustness against KPI theater — 3/10. Operational metrics have concrete customer contexts, but projected savings and undefined success rates are promoted without an economic reconciliation. (10, 22)
Decision and optimization substance
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 4/10 |
| Distinctive optimization or ML substance | 4/10 |
| Real-world constraint handling | 7/10 |
| Decision automation and labor productivity | 6/10 |
| Resilience under real operational complexity | 4/10 |
Average: 5.0/10.
Probabilistic modeling depth — 4/10. Uncertain demand and supply are explicitly acknowledged. Scenario weighting, dependencies, and calibration remain unspecified. (8, 9)
Distinctive optimization or ML substance — 4/10. Customer applications support the existence of a useful engine. The distinctive algorithm and the conditions behind its optimality claim remain inaccessible. (1, 10)
Real-world constraint handling — 7/10. The product covers meaningful production and service-parts restrictions. Published material gives less confidence in the joint economic treatment than in the breadth of represented operations. (6, 7, 20)
Decision automation and labor productivity — 6/10. Direct order promises and reported smaller planning teams indicate useful labor reduction. Sustained total-workload measurements are missing from the broader autonomy claims. (11, 12)
Resilience under real operational complexity — 4/10. The essential test is whether a costly recommendation triggers a correction to the model and better subsequent decisions. That feedback loop remains unsubstantiated. (14, 15)
Product and architecture integrity
| Criterion | Score |
|---|---|
| Architectural coherence | 5/10 |
| System-boundary clarity | 5/10 |
| Security seriousness | 2/10 |
| Software parsimony and ownership cost | 4/10 |
| Compatibility with programmatic and agent-assisted operations | 4/10 |
Average: 4.0/10.
Architectural coherence — 5/10. One application family and shared planning engines provide a recognizable structure. Adding the suite above another planner creates substantial integration responsibilities. (1, 10)
System-boundary clarity — 5/10. Coexistence with existing systems is commercially explicit. The authority to change logic, data, and external commitments is less precisely specified. (2, 15)
Security seriousness — 2/10. Dynamically generated code is a central product capability, yet its containment boundary is undocumented in the reviewed technical material. Governance assurances do not substitute for that mechanism. (2, 25)
Software parsimony and ownership cost — 4/10. Application customization, dual-system operation, and continuing delivery effort create material costs. The public architecture does not quantify the resources or maintenance needed to operate the combined applications. (1, 16)
Compatibility with programmatic and agent-assisted operations — 4/10. Automation is a deliberate product direction. Closed execution interfaces limit independent inspection and controlled maintenance of the resulting behavior. (1, 2)
Technical transparency
| Criterion | Score |
|---|---|
| Public technical documentation | 3/10 |
| Inspectability without vendor mediation | 2/10 |
| Portability and lock-in visibility | 3/10 |
| Implementation-method transparency | 5/10 |
| Evidence density behind technical claims | 3/10 |
Average: 3.2/10.
Public technical documentation — 3/10. Feature descriptions explain the intended functions. They stop short of solver mathematics, runtime controls, and an independently usable execution reference. (1, 8)
Inspectability without vendor mediation — 2/10. Understanding the engine’s actual behavior requires a vendor-mediated deployment or demonstration. Product explanations do not provide a reproducible experiment. (2, 3)
Portability and lock-in visibility — 3/10. Common languages and connections ease integration. They do not establish exportable decision logic, transferable model behavior, or an alternative runtime. (1, 16)
Implementation-method transparency — 5/10. Buyers can identify substantial delivery work, but cannot determine which future changes are included in the software price and which require a project. (14, 16, 24)
Evidence density behind technical claims — 3/10. Named operational examples are useful. Universal reasoning and optimality claims demand a much stronger technical record. (2, 10)
Vendor seriousness
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 2/10 |
| Technology roadmap integrity | 4/10 |
| Conceptual sharpness | 4/10 |
| Economic accountability | 3/10 |
| Defensibility in an agentic-software world | 5/10 |
Average: 3.6/10.
Technical seriousness of public communication — 2/10. Unbounded capability claims and categorical superiority undermine the more specific product evidence. The public explanation does not define the limits that real software necessarily has. (2, 3)
Technology roadmap integrity — 4/10. A credible maturity claim needs deployment history for the capability being sold. The public chronology supports a narrower claim than the current positioning. (3, 19, 20)
Conceptual sharpness — 4/10. Some publications recognize the importance of objectives and controlled execution. The unconstrained-agent narrative does not reconcile those requirements with its promised operating freedom. (2, 15)
Economic accountability — 3/10. Customer accounts report benefits, but cost reconciliation, failed recommendations, and the acceptance conditions behind implementation success remain unspecified. (10, 12, 22)
Defensibility in an agentic-software world — 5/10. Operational integrations and domain-specific planning functions are useful assets. Conversational access and generated code become less distinctive as agents improve; reliable decision economics must justify the additional platform. (7, 11)
Sources
Sources were accessed on November 4, 2026. Customer results below are company-published accounts; their original measurement scope is retained.
Platform architecture. Published undated; accessed November 4, 2026.
[2] Quintus general availability
Quintus general availability. Published 2026-08-12; accessed November 4, 2026.
Quintus FAQ. Published undated; accessed November 4, 2026.
Demand planning. Published undated; accessed November 4, 2026.
Inventory planning. Published undated; accessed November 4, 2026.
Supply planning. Published undated; accessed November 4, 2026.
Service parts planning. Published undated; accessed November 4, 2026.
[8] PolymatiQ and probabilistic-modeling FAQ
PolymatiQ and probabilistic-modeling FAQ. Published undated; accessed November 4, 2026.
[9] Intelligent digital agents and the planning plateau
Intelligent digital agents and the planning plateau. Published 2026-02-25; accessed November 4, 2026.
[10] Partner in Pet Food case study
Partner in Pet Food case study. Published undated; accessed November 4, 2026.
[11] Alliance Consumer Group case study
Alliance Consumer Group case study. Published undated; accessed November 4, 2026.
Quip case study. Published undated; accessed November 4, 2026.
MobilityWorks case study. Published undated; accessed November 4, 2026.
Inside ketteQ AI Studio. Published 2026-06-16; accessed November 4, 2026.
[15] Four principles for human-guided AI
Four principles for human-guided AI. Published 2026-05-19; accessed November 4, 2026.
[16] Business Architect vacancy
Business Architect vacancy. Published undated; accessed November 4, 2026.
[17] Automobile industry trends for 2022
Automobile industry trends for 2022. Published 2021-12-06; accessed November 4, 2026.
[18] Will ChatGPT transform supply chain?
Will ChatGPT transform supply chain?. Published 2023-03-28; accessed November 4, 2026.
[19] Tokyo release announcement
Tokyo release announcement. Published 2024-11-12; accessed November 4, 2026.
[20] Dubai release and semi-autonomous planning
Dubai release and semi-autonomous planning. Published 2025-05-06; accessed November 4, 2026.
[21] Intelligent digital agents general availability
Intelligent digital agents general availability. Published 2026-02-25; accessed November 4, 2026.
[22] Series B funding announcement
Series B funding announcement. Published 2025-08-05; accessed November 4, 2026.
Mike Landry appointment. Published 2022-08-15 (current page); accessed November 4, 2026.
Current homepage. Published undated; accessed November 4, 2026.
[25] Digital agents and governance
Digital agents and governance. Published undated; accessed November 4, 2026.