Anyone can wire a language model to company data in an afternoon. The demo will be great. The problem starts the week after, when the demo has to become a product that a supply chain team bets a quarter of their operating cost on.
I spent that week, and many after it, as one of two core developers on Ada — Optilogic’s agentic AI system for supply chain design, launched in June 2026.
The problem Ada solves
Supply chain design is the work of deciding where your factories, warehouses and flows should be — and it is traditionally a project, not a process. A team pulls data out of a dozen systems, cleans it for weeks, hand-builds a model, runs a handful of scenarios, and presents a deck. By the time the deck lands, the world has moved. Most companies do this once a year, ask five questions, and live with the answers.
Ada turns that project into something continuous. A user asks a question in plain language — what happens to landed cost if we close the Rotterdam DC? — and a system of agents does the work: resolves the data, builds or adapts the optimization model, runs the scenarios, and returns a quantified recommendation with every step visible and inspectable.
Optilogic’s public numbers for it: model building in a day instead of months, roughly 100× more strategic what-if scenarios answered per year, average supply chain cost reduction around 25%.
What we actually built
Publicly, Ada is five families of agents:
- Prepare — connect to the customer’s existing systems, map their data onto a supply-chain-native modeling ontology, cleanse it automatically. Model-ready in hours rather than weeks.
- Build — construct the baseline network model and generate scenarios on demand.
- Explore — run sensitivities and test strategies interactively.
- Recommend — surface the opportunities nobody asked about, quantify the impact, turn results into something executive-ready.
- Monitor — watch the live supply chain and proactively raise changes as conditions shift.
Those five families sit on top of mathematical optimization and simulation engines, inside the wider Optilogic platform. That combination is the part I find genuinely hard and genuinely valuable: the language model is not the thing producing the answer. It is the thing that understands the question, chooses the right rigorous machinery, drives it, and explains what came back. The numbers come from an optimizer, not from a model’s intuition — which is exactly why a supply chain director can defend them in a board meeting.
The thing under the five agents
Two people do not ship five families of production agents by writing five agent systems. We shipped it by building one framework and putting Ada on top of it.
We built that framework rather than taking a general-purpose one off the shelf. That decision gets argued about badly, so here is the honest version: open-source agent frameworks are excellent accelerators and I’d reach for one for a prototype without hesitating. What they are not good at is being load-bearing under a product where five distinct agent families must share one runtime, one conversation model, one persistence story, and one inspectable turn — while a genuinely enterprise set of requirements lands on top. Auditability. Predictable behaviour across wildly different requests. A codebase two people can still hold in their heads a year in.
The moment the product needs behaviour the framework didn’t anticipate, you are not extending it, you are fighting it — and every fight happens inside an abstraction you didn’t design and can’t see the bottom of. Owning the loop meant that when the requirement showed up, the answer was a named seam in our own code instead of a monkey-patch and a comment apologising for it.
That framework is the durable asset. Ada was the first product on it, and the architecture doesn’t care that the domain is supply chain: the same foundation carries internal copilots, document intelligence, workflow automation, and decision-support systems.
What made it reliable
Not prompt engineering. Prompts are the last 5% and the first thing everyone reaches for.
What made Ada reliable was architecture: a single canonical representation of conversation state, a turn cycle with exactly one place where state mutates and one place where results fold back, explicit cache invalidation, requests that fully describe themselves so a warm server never becomes the authority on configuration. Everything a customer would call trustworthy is downstream of those choices, not of a model upgrade. Ada’s request model was stateless by requirement, which made the expensive per-turn setup something the user paid for on every message — I wrote up how we got that latency back without giving up statelessness in Temporary statefulness in a stateless world.
The other half was not technical at all. Before designing a single agent we had to answer: what decisions are users actually trying to make, which workflows carry the weight, what accuracy is acceptable, and how should the system behave when the data is incomplete — which, in supply chain, it always is. Architecture only becomes meaningful after those answers exist.
What I’d carry into the next one
Enterprise AI is not an ML problem with some software around it. It’s a systems problem that happens to have a model in the middle. The teams that win the next few years won’t be the ones that adopted language models first — they’ll be the ones that built systems their own employees trust enough to stop double-checking.
If you’re trying to get something from working-demo to product-people-depend-on, that gap is the work I do.