Go back to Market Research
Manhattan Associates provides warehouse, transportation, order-management, store, and supply chain planning software. Its Manhattan Active applications coordinate physical fulfillment, inventory movements, labor, transport, replenishment, and customer orders. ActivePlanning adds demand forecasting, allocation, and inventory planning to this execution portfolio. The company also continues to support installed software alongside its Google Cloud-hosted applications. (1, 2, 3, 4)
Overall supply chain score: 5.5/10.
| Dimension | Score |
|---|---|
| Supply chain depth | 5.6/10 |
| Decision and optimization substance | 5.4/10 |
| Product and architecture integrity | 5.8/10 |
| Technical transparency | 5.6/10 |
| Vendor seriousness | 5.0/10 |
Manhattan’s strongest evidence concerns operational execution and platform engineering. Detailed release notes describe purchase-order reconciliation, warehouse-aware shipment planning, cross-docking, and automated receipt verification. Its public developer documentation explains deployment isolation, data replication, extensions, and audit mechanisms. (11, 12, 14, 15)
The weaker part is the economic decision model. Planning remains organized around forecasts, service targets, safety stock, and planner-selected scenarios. The material acknowledges demand and lead-time variability but does not expose a joint probabilistic model that values competing inventory, transport, and fulfillment actions. The marketing also overstates what several pieces of evidence establish: a retrospective M5 ranking lacks a reproducible public protocol, regenerated code supposedly eliminates technical debt, and prompt instructions supposedly guarantee reliable agent behavior. Meanwhile, customization remains substantial paid work. (6, 7, 9, 22, 26)
Manhattan versus Lokad
Manhattan manages operational transactions and the people and equipment carrying them out. A warehouse needs receiving, inventory records, task assignment, picking, packing, shipping, and connections to automation. A transport operation needs shipment creation, carrier interaction, tendering, tracking, and settlement. These functions remain necessary regardless of the quality of a company’s forecasts. Manhattan supplies much of that execution environment. (3, 4)
Lokad concentrates on the economic decisions that direct those operations: how much to purchase, where to place stock, which demand to serve, and when an expensive transfer or alternative source is justified. The perspective behind its inventory optimization and Introduction to Supply Chain treats uncertainty and financial consequences as the starting point. A maintained numerical recipe should produce ordinary decisions; practitioners improve the recipe and its assumptions rather than repeatedly arbitrate individual items.
For example, Manhattan can consolidate a shipment while accounting for warehouse pick sequence, transport capacity, and delivery requirements. Deciding whether the shipment should be expedited also requires valuing the lost sales and customer consequences of waiting, the uncertain arrival of alternative stock, and the best competing use of the inventory. An execution-feasible route is one part of this economic decision. A shared application data model does not establish a shared financial objective.
The two vendors can therefore occupy different layers of the same system. Manhattan can execute purchases, transfers, and fulfillment while an external decision engine determines their quantities and priorities. Manhattan’s APIs and event interfaces support that separation in principle; actual integration must preserve ownership of decisions and prevent competing rules from silently rewriting them. Its own planning module instead keeps forecasting, service policies, replenishment, and allocation within the execution vendor’s product family. (2, 17)
Decisions, uncertainty, and optimization
Execution contains specific decision mechanisms
The 26.2 release describes shipment planning that considers warehouse allocation, cubing, and the discrete pick sequence when splitting orders. Grouping pallets according to their positions along the pick path can avoid a transport plan that saves freight while creating excessive warehouse travel. That is a concrete interaction between operational domains. The release also describes automated receiving and agent integration into existing extension workflows. (12)
ActivePlanning’s 26.3 release similarly exposes meaningful detail. Host Order Import reconciles purchase orders split or merged in an execution system while preserving their original planning references. Flow Through consolidates lower-echelon needs into a vendor order and pushes receipts through a parent distribution center without requiring long-term storage there. These capabilities address the state reconciliation on which usable decisions depend. (11)
Forward Buy on the Fly introduces a narrower economic calculation: users configure discounts, price increases, carrying costs, and borrowing rates, then apply a selected result to suggested orders. This provides more substance than a generic inventory-reduction claim. Its disclosed interface remains a simulation chosen by a planner; the release does not show an automatic comparison against all competing purchases, cash uses, expiry risks, and uncertain demand outcomes. (11)
Service targets remain the planning center
The replenishment suite supports pack sizes, shelf life, inventory transfers, supplier outages, seasonal lead-time adjustments, and rules-based approvals. It can automate ordinary order handling and restrict transfers of high-risk or expiring stock. These details matter for deployed decision production. (5)
Its Service Investment Strategies capability, however, still asks planners to set differentiated service targets and compare their safety-stock costs. It explicitly uses ABC velocity classifications and segmentation by revenue or units. Revenue and sales frequency do not determine the marginal economic value of another unit: margins, substitution, shortage consequences, expiry, and capital competition can differ sharply within the same class. Moving from a blanket target to differentiated targets improves a policy system without establishing an economically adequate objective. (6)
The MEIO page says it accounts for variability in both demand and lead times. It does not explain how those uncertainties are represented, calibrated, and combined across items, sites, and suppliers, or how the resulting distributions enter decisions. The public page explains safety-stock placement and interdependence at a functional level; it does not expose a joint stochastic economic optimizer. (7)
Forecasting methods are identified, but superiority is not established
The UFM.ai whitepaper names components drawn from Croston’s method, variable-response exponential smoothing, Holt-Winters, and ARIMA/SARIMA, combined into a statistical formulation augmented by machine learning. It describes using that statistical foundation when external data is poor and adapting to additional factors when it is useful. This is a more specific explanation than simply labeling the forecast AI. The equations, learning procedure, and reproducible ablation results are absent. (8)
The same document claims that hybrid modeling is more accurate and dependable than alternatives, partly invoking the M4 competition. A successful hybrid method in a competition does not validate Manhattan’s particular combination or its performance on a different population of retail decisions. The whitepaper’s anonymous examples report inventory, service, and revenue changes, but do not identify the customers, complete evaluation periods, or implementation costs.
A forecast can also improve a statistical loss without improving an order. Overpredicting a high-margin spare part and overpredicting a perishable low-margin item have different economic consequences. Manhattan’s disclosure does not establish how forecasting improvements are translated into the value of the next purchase, transfer, or allocation rather than into a revised service-policy calculation.
The retrospective M5 claim needs its actual protocol
Manhattan’s planning page dates its M5 comparison to 2025. The dedicated benchmark page reports placement in the top 1.4% relative to more than 5,500 original teams, describing the result as blind, independently scored, and produced by the model used in its current product. It identifies Walmart daily sales and the product-location hierarchy. These are vendor claims about a later comparison with the competition, rather than evidence of a Manhattan entry in the original 2020 contest. (9, 31)
The public page omits the numerical score, named independent evaluator, forecast file, training cutoff, evaluation horizon, tuning protocol, and results by aggregation level. It discusses both the accuracy and uncertainty tracks without separately reporting Manhattan’s results for them. The organizers distinguish the point-forecast WRMSSE ranking from the probabilistic WSPL ranking and publish evaluation resources by series, horizon, and hierarchy level. A point-forecast percentile does not establish distributional forecasting quality. (9, 10)
Retrospective testing also needs explicit controls against using already-public evaluation outcomes during model selection. Manhattan’s statement that testing was blind is relevant, but the undisclosed protocol prevents independent verification of what was withheld and from whom. Publishing the evaluation artifacts and model-selection procedure would make the comparison testable.
Nor does a high rank imply a particular percentage accuracy, SKU/store performance, or economic return. Hierarchical scores combine errors at different levels, while replenishment happens at specific items and locations. The missing operational test connects forecasts available at an order date to the resulting stock, waste, service, and profit after lead times and ownership costs. The page’s leap from a benchmark ranking to real-world decision validation goes beyond the result it discloses.
Transportation optimization: faster search within which model?
Manhattan’s continuous-optimization page describes in-memory caching, a multimodal solver, and automatic selection among route-generation techniques. It says a probabilistic analysis of the transport network determines which algorithms to use, reducing manual configuration. This is an identifiable adaptive-search mechanism. The description does not show that future demand, travel disruptions, uncertain arrivals, and downstream inventory consequences are jointly modeled. (13)
The page claims up to tenfold speed gains and solve-time reductions of up to 80%, without a public instance set, hardware specification, comparison baseline, or economic evaluation. The two maxima should not be treated as measurements of the same run. More importantly, solver speed does not establish model fidelity. Delivery promises, stockouts, warehouse congestion, and alternative actions need adequate representation before optimizing them has business meaning.
Lokad’s Holimization perspective makes this distinction explicit: improving an optimization model includes changing its objective and available decisions. Manhattan documents extension mechanisms and operational parameters, but does not expose an equivalent process for revising the optimizer’s economic formulation. Automatic parameter tuning cannot add an economically important mechanism that the model omits.
Technology history and roadmap integrity
| Period | Public proposition | What the follow-through shows |
|---|---|---|
| 2011–2012 | SCOPE’s Supply Chain Process Platform promised a common data model, service-oriented architecture, and cross-application optimization. | Unified planning and execution was already a central proposition; it is not a new consequence of adding agents. (27) |
| 2017 | Active Omni launched as cloud-native, versionless, and extensible. | The current developer documentation and recurring releases provide evidence of a sustained architectural program. (28, 14) |
| 2019–2020 | Manhattan’s magazine promoted warehouse AI and machine learning while warning against AI gimmicks. | Its article distinguished future assistants from then-current operational algorithms. That restraint is useful; the broader prediction claims still lacked disclosed evaluations. (29) |
| 2020 | Active Warehouse Management launched with microservices, order streaming, and machine-learning orchestration of workers and automation. | Later release notes and customer throughput results support continued execution development. (30, 12, 24) |
| 2025 | Hybrid AI and a retrospective M5 comparison became prominent planning claims. | Named statistical components are disclosed; the benchmark protocol and economic attribution remain incomplete. (8, 9, 31) |
| 2026 | Agents, MCP interoperability, and faster deployment are promoted across the suite. | The release notes distinguish background actions from interactive assistants. The October recap also advances an unsupported claim that nightly code generation eliminates technical debt. (12, 23, 26) |
This history supports a substantive cloud and execution roadmap. It also reveals how often the same higher-level promise—unified decisions with less implementation friction—is presented through a new technology vocabulary. The relevant test is what manual work, interfaces, and maintenance obligations actually disappeared between generations.
The 2019 article is particularly useful for assessing early AI rhetoric. It advocated operational algorithms and put conversational shopping assistants in the future. The 2020 warehouse launch then identified a specific task: coordinating orders, workers, and automation. These claims are narrower than enterprise intelligence or autonomous supply chain management, and should be judged as such. The current agent catalog contains a mixture of similarly bounded automation and conversational assistance, despite the broader language surrounding it. (29, 30, 23)
Software materials and security
A documented but substantial software estate
| Component | Attributable role | Ownership implication |
|---|---|---|
| Java, Spring, Debian-based OpenJDK images, Docker, Google Kubernetes Engine | Application runtime and container deployment. | A defined runtime with image-building and vulnerability-scanning mechanisms, plus substantial orchestration machinery. (14, 15) |
| More than 250 microservices | Application, system, and lifecycle services in the documented platform. | Many deployment units, interfaces, and failure boundaries to maintain; the count is not a count of services used by every customer. (14) |
| MySQL / Google Cloud SQL | Production persistence and supported replicated databases. | Transactional state and downstream replicas require synchronization, schema compatibility, and recovery. (19) |
| RabbitMQ and Elasticsearch | Messaging and indexing services identified in the security documentation. | Additional stateful components with their own capacity, patching, and recovery requirements. (15) |
| Google Pub/Sub | External asynchronous integration and audit streams. | Service-account and message-contract administration remains part of integration ownership. (15, 16) |
| Kafka, Spring Boot, and the MySQL binlog connector | Manhattan’s Gravina change-data-capture pipeline. | A second messaging mechanism has a specified replication role; data portability requires an operated pipeline rather than a simple file export. (19) |
| Rubik | Manhattan’s containerized deployment framework, using scripts and Kubernetes specifications. | Provider-controlled lifecycle tooling abstracts infrastructure but does not remove the cost of maintaining it. (14) |
Public documentation assigns these components distinct roles. Together they carry a substantial operating burden: several stateful systems, replication, container scheduling, extension execution, and application services must remain compatible.
An October 2026 vendor account quotes the CTO saying about 75% of a 60-million-line platform is regenerated nightly and that this leaves no technical debt. Generated code can reduce repetitive implementation work. It cannot eliminate debt in schemas, business semantics, generators, dependencies, test coverage, or the remaining handwritten software. Code volume and regeneration frequency establish neither simplicity nor correctness. The claim is especially weak beside the company’s own acknowledgment that software complexity imposes a cost. (26)
Isolation, integrations, and agent authority
Manhattan’s public security guide describes a separate Google project and VPC for each customer environment, with resource and network isolation. It separates application endpoints from restricted administrative endpoints and explains scoped service accounts and propagation of user, organization, and tenant context through asynchronous processing. These are architectural controls with a recognizable threat boundary. (15)
The same guide exposes a consequential exception: custom integrations can make unencrypted outbound calls, which are discouraged rather than forbidden. The security of data leaving the platform therefore depends partly on customer-specific integration choices. The audit guide supplies activity streams and change detection, with much of the latter primarily visible to Manhattan operations. (15, 16)
Agent Foundry adds predefined authorized API services, administrator-configured controls, and content sanitization. The API restriction is a meaningful containment mechanism. Its FAQ then claims that instructional guardrails guarantee obedience to system instructions and prevent fabricated responses. Prompt instructions provide no such guarantee. The security question is what a mistaken or manipulated agent can read and change despite its instructions, with authorization and action limits enforced outside the model. The reviewed material does not fully explain that boundary for customer-built workflows and remote tools. (22)
Custom Java extensions also have a specific boundary: the developer glossary says that custom extension components running inside the platform can be developed and deployed only by Manhattan’s professional-services team. Public low-code and API customization is broader. These mechanisms should be distinguished when assessing who can execute code beside production data and who bears the development and maintenance cost. (18, 21)
Configuration maintenance, portability, and total cost
The extension documentation describes hundreds of business settings, custom data attributes, synchronous and asynchronous hooks, UI extensions, and external services. The glossary warns that synchronous handlers can introduce latency and require performance testing. This is continuing software engineering, even when a visual interface generates the implementation. (17, 18)
Versionless delivery can remove disruptive base-product upgrade projects. It does not remove the need to verify that custom rules still express the intended business decisions after changes in products, suppliers, channels, or operational constraints. An extension can remain API-compatible while becoming economically wrong. Agent-generated extensions add another authoring mechanism; they do not remove responsibility for tests, rollout, observability, and rollback.
The financial filing puts scale behind this issue. Manhattan reported $503 million of services revenue in 2025, 47% of total revenue; about 75% of services revenue related to cloud subscriptions. It says customers continue buying services for additional locations, features, products, and support after initial implementation. Services are generally billed by the hour under time-and-materials contracts. These figures cover expansion as well as maintenance and do not measure waste. They establish that cloud delivery still involves considerable paid human work. (1)
For economic accountability, hourly delivery creates a clear boundary: payment follows work performed, not automatically the customer’s realized profit. The buyer therefore needs a baseline, complete ownership costs, and responsibility for correcting model or configuration defects. Public case summaries do not supply this accounting. More consulting, more review, or more agent configuration must be charged against the claimed productivity improvement.
Portability has both strengths and constraints. Data Stream documents MySQL replication into vendor-managed or customer-managed Cloud SQL, while APIs expose business functions and configuration. That provides an operational exit route for data. It does not establish equivalent portability of the configured decision logic, extension behavior, or agent policies. The Developer Hub separately places proprietary OpenAPI specifications under confidentiality terms. Public conceptual documentation is extensive; detailed interface inspection is partly restricted. (17, 19, 20)
Agents and labor productivity
Manhattan’s agent catalog contains materially different kinds of work. The Verify ASN Agent checks whether receipts are complete and closes them in the background. Other agents extract shipping or invoice information from documents and create operational records. These are concrete transactions removed from a person’s queue. Wave Coordinator instead investigates shortages and recommends alternatives; Inventory Operations offers a natural-language interface for settings, outages, errors, and tickets. The latter can speed an existing workflow while preserving its need for human attention. (23)
The 26.2 release adds MCP Connect and Remote MCP so external agents can invoke Manhattan tools and Manhattan agents can use tenant-registered external servers. Standardizing tool access is an inexpensive integration step compared with designing and validating autonomous economic decisions. It earns no optimization credit by itself. Using agents to reproduce the same sequence of item review, inquiry, and approval risks preserving the principal labor bottleneck under a conversational interface. (12)
The release also supports schedules, background monitoring, and synchronous or asynchronous invocation from extensions. Those capabilities can avoid interactive use. The assessment must therefore distinguish connector availability from the decisions actually automated, and measure unattended completion, exceptions, human correction, and maintained workload per practitioner. The published catalog and conference accounts do not provide those measures across a representative planning deployment.
Pet Supplies Plus reports moving from approximately 170–180 to 240–250 units per hour after several changes, including reslotting, equipment, volume growth, and Manhattan Active WMS. It also reports shortening order-to-shipment time by a day. The June 2025 account quotes its executive attributing more than 15–20% of the improvement to the WMS; the current summary says the WMS drove a 15–20% productivity increase. The summary does not explain how it moves from a lower bound on the software’s share of a combined improvement to a percentage gain attributed to the software itself. (24, 25)
The detailed account is the better basis for attribution because it preserves the other changes and the customer’s qualification. It also says adoption of ActivePlanning was intended for 2026. The earlier warehouse gains cannot establish the performance of that later planning deployment or its new agents.
The October 2026 recap adds reports of fewer inventory transfers at SP Richards and customer-service inquiries deflected by Maven. These are relevant task outcomes, but neither fewer transfers nor a deflection rate alone determines net benefit. The necessary follow-through is delivery performance, costs, customer resolution quality, and total human effort, including work displaced into exceptions and support. (26)
Supply chain score
The 25 criteria carry equal weight. Each dimension is the average of its five criteria; their unrounded overall mean is 5.48, displayed as 5.5/10. Scores reflect the disclosed mechanisms and results rather than the breadth of the product catalog alone.
Supply chain depth
| Criterion | Score |
|---|---|
| Economic framing | 6/10 |
| Decision end-state | 8/10 |
| Conceptual sharpness on supply chain | 6/10 |
| Freedom from obsolete doctrinal centerpieces | 4/10 |
| Robustness against KPI theater | 4/10 |
Average: 5.6/10.
Economic framing — 6/10. Freight cost, inventory investment, spoilage, forward-buy discounts, and borrowing costs are concrete economic inputs. The public decision model remains fragmented across execution costs and service-policy calculations rather than an exposed joint valuation of actions. (5, 11, 13)
Decision end-state — 8/10. Warehouse tasks, shipment plans, purchase orders, receipts, and replenishment are operational outputs with specified execution mechanisms. This is the strongest part of Manhattan’s case; economic superiority of each decision is less well established. (11, 12, 23)
Conceptual sharpness on supply chain — 6/10. Purchase-order reconciliation, cross-docking, warehouse-aware shipment splitting, and sourcing constraints demonstrate detailed knowledge of execution. The planning philosophy is less precise about uncertainty and the financial value of competing actions. (5, 11, 12)
Freedom from obsolete doctrinal centerpieces — 4/10. Continuous execution and rule-based release move beyond periodic manual planning. Service targets, ABC classes, safety-stock scenarios, and recurring planner arbitration still anchor the inventory methodology. (5, 6)
Robustness against KPI theater — 4/10. Some customer reports provide actual throughput and operational changes. The incomplete M5 protocol and unexplained change in the Pet Supplies productivity measure weaken the broader conclusions drawn from those results. (9, 24, 25)
Decision and optimization substance
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 3/10 |
| Distinctive optimization or ML substance | 6/10 |
| Real-world constraint handling | 7/10 |
| Decision automation and labor productivity | 6/10 |
| Resilience under real operational complexity | 5/10 |
Average: 5.4/10.
Probabilistic modeling depth — 3/10. MEIO explicitly mentions demand and lead-time variability. The hybrid forecast and adaptive transport descriptions do not expose calibrated joint uncertainty or its use in a common economic decision model. (7, 8, 13)
Distinctive optimization or ML substance — 6/10. Statistical components, adaptive route generation, and warehouse-aware shipment decisions are identifiable. Their formulations and independently reproducible current evaluations are too limited to support the strongest superiority claims. (8, 12, 13)
Real-world constraint handling — 7/10. Pack sizes, shelf life, warehouse picking, cross-dock flows, and host-order changes receive concrete treatment. The limitation is the economic and stochastic completeness of the model rather than absence of operational detail. (5, 11, 12)
Decision automation and labor productivity — 6/10. Background receipt verification, document processing, and rules-based order approvals remove work. Customer throughput evidence is useful, but total planning labor and the maintenance effort of agent-enabled deployments remain unmeasured publicly. (5, 23, 24)
Resilience under real operational complexity — 5/10. Audit trails expose configuration changes, while extension hooks and ProActive’s packaged migrations support revised application logic. The optimizer’s economic formulation remains less accessible: the documentation does not demonstrate adding an omitted interaction, comparing the resulting decisions on preserved workloads, and promoting a validated model correction. (16, 17, 21)
Product and architecture integrity
| Criterion | Score |
|---|---|
| Architectural coherence | 6/10 |
| System-boundary clarity | 7/10 |
| Security seriousness | 6/10 |
| Software parsimony and ownership cost | 3/10 |
| Compatibility with programmatic and agent-assisted operations | 7/10 |
Average: 5.8/10.
Architectural coherence — 6/10. The platform documentation describes common deployment, messaging, extension, and lifecycle mechanisms. More than 250 services and multiple stateful subsystems still carry coordination costs, while shared infrastructure does not prove one coherent economic optimizer. (14, 19)
System-boundary clarity — 7/10. Host-order reconciliation, API and message integration, customer-environment boundaries, and replication ownership are described explicitly. These interfaces help distinguish the execution system from external systems and decision logic. (11, 15, 17, 19)
Security seriousness — 6/10. Project/VPC isolation, scoped identities, and audit mechanisms merit credit. Custom outbound communication and the overstatement of prompt-based guarantees limit confidence in the complete containment of integrations and agents. (15, 16, 22)
Software parsimony and ownership cost — 3/10. The disclosed software mass and services business make continuing ownership work tangible. Versionless updates and generated code do not demonstrate low maintenance costs for customer-specific behavior. (1, 14, 17, 26)
Compatibility with programmatic and agent-assisted operations — 7/10. APIs, events, background agents, and extension hooks enable substantial automation. MCP adds another access mechanism; its availability should not be confused with autonomous economic competence. (12, 17, 23)
Technical transparency
| Criterion | Score |
|---|---|
| Public technical documentation | 7/10 |
| Inspectability without vendor mediation | 5/10 |
| Portability and lock-in visibility | 5/10 |
| Implementation-method transparency | 6/10 |
| Evidence density behind technical claims | 5/10 |
Average: 5.6/10.
Public technical documentation — 7/10. The developer portal explains actual architecture, security, extension, and replication mechanisms. Optimization formulations and current predictive validation are substantially less transparent than the platform. (14, 15, 17, 19)
Inspectability without vendor mediation — 5/10. A technical reader can inspect much of the platform design publicly. Proprietary OpenAPI specifications carry confidentiality conditions, and the M5 result lacks the artifacts necessary for independent reproduction. (9, 20)
Portability and lock-in visibility — 5/10. Data Stream explains how data can reach a customer-managed database. Configured workflow semantics, custom extensions, and agent behavior remain more tightly dependent on Manhattan’s runtime and service boundaries. (17, 18, 19)
Implementation-method transparency — 6/10. Public documents identify extension latency, business settings, API configuration, provider-only custom components, and ongoing professional services. They do not quantify lifecycle effort for a representative deployment. (1, 17, 18)
Evidence density behind technical claims — 5/10. Release notes and architecture guides substantiate many operational claims. The comparative forecasting, universal optimization, and technical-debt claims exceed the disclosed evaluations. (9, 11, 12, 26)
Vendor seriousness
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 4/10 |
| Technology roadmap integrity | 6/10 |
| Conceptual sharpness | 5/10 |
| Economic accountability | 4/10 |
| Defensibility in an agentic-software world | 6/10 |
Average: 5.0/10.
Technical seriousness of public communication — 4/10. Detailed engineering documentation is undermined by claims that prompt instructions guarantee reliability and that nightly regeneration eliminates technical debt. The benchmark page asserts proof while withholding the protocol needed to assess it. (9, 22, 26)
Technology roadmap integrity — 6/10. The progression from Active Omni to warehouse execution and current operational releases shows sustained delivery. Repeated unification claims and the new agent layer still need evidence of reduced integration work and total ownership cost. (27, 28, 30, 12)
Conceptual sharpness — 5/10. Manhattan distinguishes some interactive and background agent roles and understands physical execution dependencies. Its broader narrative too readily equates better forecasts, shared data, and faster workflows with better supply chain economics. (2, 9, 23)
Economic accountability — 4/10. The detailed Pet Supplies account preserves several causal qualifications, and the filing exposes the services model. Public evidence still does not connect complete lifecycle costs to attributable profit or assign responsibility for persistently poor decision logic. (1, 24, 25)
Defensibility in an agentic-software world — 6/10. Transactional execution, warehouse integration, and operational constraints give Manhattan substance beyond a chat interface. Preserving those strengths requires using agents to remove recurring work, rather than merely adding more ways to navigate and configure the same large application estate. (11, 12, 23)
Sources
Sources were reviewed on November 4, 2026. Customer outcomes are attributed reports; comparisons distinguish the period, product, and metric actually described.
[1] Manhattan Associates 2025 Form 10-K
Annual filing. Manhattan Associates, filed February 4, 2026. Product scope, cloud hosting, professional-services revenue, billing model, and continuing customer services.
ActivePlanning overview. Manhattan, current product page. Forecasting, replenishment, allocation, and relationship to execution applications.
Warehouse management. Manhattan, current product page. Warehouse, labor, automation, and fulfillment functions.
Transportation management. Manhattan, current product page. Planning, execution, carrier, fleet, and settlement perimeter.
Inventory replenishment. Manhattan, current product page. Shelf life, order approvals, supplier changes, transfers, and buying opportunities.
[6] Service investment strategies
Service Investment Strategies. Manhattan, undated. Service targets, ABC segmentation, safety-stock simulation, and financial comparisons.
[7] Multi-echelon inventory optimization
MEIO description. Manhattan, undated. Network inventory placement and explicit demand/lead-time variability claim.
[8] Hybrid forecasting whitepaper
Beyond Traditional Forecasting: The Hybrid AI Advantage. Manhattan, undated. UFM.ai’s named statistical components, combination with ML, and anonymous customer examples; especially printed pages 7–9.
[9] Manhattan’s M5 benchmark page
M5 benchmark claim. Manhattan, current page discussing its retrospective evaluation. Top-1.4% claim, asserted blind independent scoring, and description of competition tracks.
[10] M5 organizers’ evaluation resources
M5 methods repository. M5 competition organizers, fixed repository revision. Describes the separate WRMSSE/WSPL evaluations, submissions, and breakdowns by series, horizon, and aggregation.
Waypoints Supply Chain Planning 26.3. Manhattan, 2026. Host-order reconciliation, forward buying, currency handling, and cross-dock replenishment.
Waypoints Supply Chain Execution 26.2. Manhattan, 2026. Shipment/pick-sequence coordination, agents, schedules, extension invocation, MCP Connect, and Remote MCP.
[13] Continuous transportation optimization
Continuous Optimization. Manhattan, undated current page. In-memory caching, algorithm selection, reduced configuration, and performance claims.
[14] Platform technology overview
Technology Overview. Manhattan developer documentation. Java/container architecture, more than 250 microservices, image construction, and Rubik deployment framework.
ActivePlatform Security. Manhattan developer documentation. Customer-environment isolation, identities, communication, administrative boundaries, and documented exceptions.
Auditability. Manhattan developer documentation. Activity streams, extension/configuration tracking, and change-detection access.
[17] Extensibility and configuration
Extensibility & Configurability. Manhattan developer documentation. Business settings, data attributes, extension hooks, APIs, UI changes, and external integration.
Glossary. Manhattan developer documentation. Synchronous handler behavior, performance implications, and provider-only development of custom Java extension components.
Data Stream. Manhattan developer documentation. MySQL logs, Gravina, Kafka, replication targets, and customer/vendor operating responsibilities.
[20] API confidentiality terms
Developer Hub Confidentiality Agreement. Manhattan, current published terms. Governs access to proprietary OpenAPI specifications separately from public conceptual documentation.
ProActive low-code platform. Manhattan, current product page. Customer customization and extension authoring environment.
Agent Foundry. Manhattan, current product page and FAQ. Agent construction, API restrictions, administrator controls, and claims about instructional guardrails.
Ready-to-deploy agents. Manhattan, current catalog. Distinguishes background transaction handling, operational investigation, and interactive assistance.
[24] Detailed Pet Supplies Plus account
Pet Supplies Plus Shares Efficiency Wins with Manhattan. Manhattan, June 13, 2025. Throughput, other operational changes, customer attribution, order-cycle gains, and later planning ambitions.
[25] Pet Supplies Plus summary
Pet Supplies Plus customer page. Manhattan, current undated summary. Presents the productivity attribution differently from the detailed account.
[26] October 2026 conference recap
Notes from Milan: humans are still the pilots, not the passengers. Manhattan, October 19, 2026. Executive claims about code generation, technical debt, deployment times, and customer task outcomes.
[27] Manhattan Associates 2011 Form 10-K
2011 annual filing. Manhattan Associates, 2012 filing for fiscal 2011. SCOPE, service-oriented architecture, cross-application optimization, and the earlier shared-platform proposition.
First Omni-Channel-as-a-Service Platform. Manhattan release, May 9, 2017. Initial cloud-native, versionless, extensible Omni proposition.
[29] Manhattan’s 2019/2020 magazine
Commerce Trends 2019/2020. Manhattan-authored magazine, publicly hosted by The Hive Network. Printed pages 10–11 contain Craig Summers’ discussion of AI gimmicks, warehouse algorithms, and future conversational assistants.
[30] Active Warehouse Management launch
Cloud-native WMS announcement. Manhattan, May 20, 2020. Microservices, order streaming, and machine-learning coordination of automation and workers.
[31] Planning overview and benchmark date
Supply chain planning overview. Manhattan, current product page. Explicitly dates the retrospective M5 comparison to 2025.