Inhaltsübersicht

Putting an AI assistant on a planning platform designed in the 1990s does not make the platform intelligent. It is a jet engine on a horse cart: the engine is impressive, but the cart still sets the speed limit.

In the first installment of our Bolted On vs. Built In series, we looked at why bolted-on AI inherits the limits of the system beneath it. The next question is what an AI-native architecture has to deliver instead.

A useful test is to ask what the AI can actually do. It can Retrieve: answer questions about the current plan. It can Recommend: suggest actions based on patterns or rules. Or it can Resolve: test scenarios against operational constraints, compare trade-offs, and support execution within defined permissions, business rules, and approval requirements. When evaluating a platform, ask whether its AI can move beyond Retrieve and Recommend to Resolve.

In our white paper, Bolted On vs. Built In, Rick McDonald and I explore four architectural capabilities that distinguish AI-native planning from traditional systems.‍

1. Current Data, Not Copies

Supply chains change constantly. Demand shifts, suppliers slip, and capacity disappears without warning. AI can only respond well when it works from current conditions.

Many bolted-on systems move data out to a separate AI service on a schedule. The AI then reasons over a snapshot, while the solver that has to act on its advice sits somewhere else, working from its own copy. Ask that kind of assistant how a supplier delay will affect next week's customer commitments, and the answer reflects yesterday's data.

In an AI-native architecture, the planning data, the solver, and the AI reasoning work together as a single solution. A recommendation is built on current data and tested against the same constraints under which it will be executed.

2. Open-Ended Questions, Not Predefined Workflows

Traditional planning systems answer the questions their developers anticipated. Anything else needs configuration or manual work.

That limit matters more with agentic AI, because supply chain leaders do not know in advance which questions they will need to ask. A tariff change, a demand spike, or a capacity shortage can call for a scenario nobody built ahead of time.

An AI-native architecture lets agents work through unscripted questions using the planning functions and data in the platform. At ketteQ, Quintus™ lets users ask planning questions and coordinate intelligent agents without configuring every scenario in advance.

Open-ended does not mean unbounded. A language model can interpret a question well, but it cannot guarantee a plan that respects capacity, inventory, and sequencing limits. The freedom to ask anything only matters when every answer is tested against real constraints, and when people approve the actions that follow.

3. A Solver the AI Can Call, Not Hours of Processing

AI reasoning is only as useful as the engine it can call on. Language models are strong at interpreting intent and weak at guaranteeing feasibility. To solve real planning problems, AI needs a deterministic solver to reason with, and that solver has to be fast enough for an agent to use.

Many legacy engines need hours to complete complex calculations. That worked for weekly or monthly cycles. It does not work for an agent expected to test alternatives continuously.

Consider a manufacturer deciding whether to shift production between facilities after a disruption. The decision touches inventory, transportation cost, capacity, and customer service. If every calculation takes hours, experimenting with alternatives is impractical.

PolymatiQ™ Solvers, ketteQ's patent-pending solver technology, evaluate feasible options against capacity, inventory, sequencing, and other operational constraints in seconds. Quintus™ takes the question and coordinates the agents. PolymatiQ™ Solvers do the work of computing a plan that holds up.

Solver speed is not just a performance metric. It determines whether AI can experiment and act, or only describe.

4. Deployment Neutrality, Not Vendor Lock-In

Adopting advanced AI should not require replacing the systems you already run. Most enterprises operate across multiple ERPs, planning applications, and business platforms, and replacing them brings cost, complexity, and disruption.

A fair question follows. If Quintus™ sits above other systems, is it not a sidecar too? Position is not the test. Capability is. A sidecar reads the outputs of a planning engine that was never designed to be called by agents. Quintus™ is wired directly into PolymatiQ™ Solvers, so agents act on real planning capability and not on a copy of its outputs.

That is what lets an AI-native platform connect to existing systems of record without inheriting their limits. Models and agents will keep changing, and open interfaces let new capabilities plug in without another round of extensive customization.

The goal is not to replace every system just to introduce AI. It is to make sure the AI has the intelligence and capabilities it needs to improve planning decisions.

How to Evaluate an AI-Native Supply Chain Platform

Feature lists and polished demos do not always reveal the architecture. Ask vendors how current their data is, whether their AI can handle an unfamiliar disruption, which operational constraints shape the proposed plan, and how the platform connects to the systems you already run. Have them demonstrate their answers using a disruption you choose.

The answers reveal whether AI can support continuous planning decisions or primarily explain the current plan. Moving from Retrieve and Recommend to Resolve should translate into practical business value: faster responses to disruptions, better customer service, and clearer cost trade-offs.

Explore the Architecture Behind Free-Range AI™

In Bolted On vs. Built In: The Supply Chain AI Architecture Question Nobody Is Asking, Rick McDonald and I examine why architecture determines the future of intelligent supply chain planning.

Download the white paper to explore what separates AI-native platforms from legacy systems and discover the questions to ask during your next AI evaluation.

Auf sozialen Medien teilen:

Über den Autor

Chris Amet
Chris Amet
Leiter der Technologieabteilung

Chris verfügt über mehr als 20 Jahre Erfahrung in der Konzeption, Entwicklung und Implementierung innovativer Softwarelösungen in einer Vielzahl von Marktsektoren.

Seine anerkannte Expertise in der Nutzung neuer Technologien zur Lösung komplexer Supply-Chain-Probleme wird entscheidend dazu beitragen, die bereits innovative Produktentwicklung und Technologiestrategie von ketteQ auf ein neues Niveau zu heben. Bevor er zu ketteQ kam, hatte er Schlüsselpositionen in der Produktentwicklung und Führung bei Genpact, Barkawi Management Consultants, Servigistics, Lockheed Martin und General Dynamics inne.

Chris erhielt seinen Bachelor of Science in Elektrotechnik und Elektronik von der Drexel University.

‍