Introduction
The task in the AI Strategy Lab was to select a real-world company, rethink one of its processes with an emerging technology, and implement the process from the initial problem definition to prototyping, evaluation, and recommendation. The point was not to theorize on the nature of AI and its potential but to feel the practical aspects of its implementation: costs, dependencies, weaknesses, and need for trust.
Our Team(Team 23) consisted of four members from four different countries: China, Hungary, Czechia and Austria. Being international was a definite advantage to us, especially because we were working on the Czech market, for which a member of the team knew the local environment well. Our team was diverse: some of us were oriented toward pricing and numbers, others saw things through the ecosystem and platform perspective, and others understood the practical aspects of workflow. And our best insights emerged in moments when these perspectives met.
Summary of the final project
This work was connected with replenishing about 300 gas stations belonging to MOL in the Czech Republic. Every gas station offers some 1,500 product items; each station has its own profile of customers, and there are two levels of delivery – regular deliveries to the gas stations and a warehouse with longer delivery intervals. The ordering process is based mainly on experience and previous sales results, and therefore, one hand you have empty shelves, and on the other hand – overstock.
Our third and final proposed solution is very focused. MOL currently uses forecasting through machine learning algorithms and a set price or confidence level that either triggers automatic ordering or escalates it to human intervention. What is important about this is that this decision process only considers values generated by the model itself. It has no means of knowing about delays communicated through e-mail, the road conditions preventing deliveries or equipment breakdown. To address this issue, we included the context-aware agent which is able to adjust the confidence of the forecast based on such real-time events before the decision is made whether to automatically send an order or escalate it for human review.
Decisions, obstacles and feedback
Starting from the core problem, not the fancy one. Throughout the brainstorming process we kept running into the same problem – how can we solve something that is going to be truly painful to the people performing the tasks, rather than just look cool or add some marginal value? This is how we settled on gas stations’ inventory management. It is a mundane, costly and real problem that requires people to assemble orders manually and any error will immediately show on empty shelves. Initially, our idea revolved around developing an AI agent that would predict demand, optimize inventory levels, and carry out re-supply automatically, saving a lot of manual labor for humans.
It was the feedback that really transformed things. Our professor mentioned that agentic re-supply and auto-reorder wasn’t anything new – licensed solutions were doing just that. It was quite a shocker but the best feedback we ever had. Since forecasting and ordering were already commoditized, we had to think about the part of the process that wasn’t. The point when the system chooses whether to act on its own or call in humans and why was rule-based and oblivious to any variables beyond the models.
Narrower scope, tougher questions. Pivot changed our thinking about almost everything:
• Business model: MOL stations in the Czech Republic are company owned and operated. Built via acquisition of existing networks of stations, rather than franchises. That means no sales price exists. We’ve designed a cost allocation model for MOL – one-off setup cost and a monthly per-station cost including a base connection fee and a complexity scaled element, illustratively totalling to something like €13,500 per month. That was based on online benchmarks and assumption about a station size mix and should be considered as a hypothesis, not a fact.
• Ecosystem: As we sit atop the existing forecasting and POS systems, vendors who were initially identified as competitors became complementors for us. Our solution has been positioned as a Customer Proxy, which operates on behalf of station managers in strict guardrails, within a defined process.
• Defensibility: LLM alone can easily be copied. It is impossible to copy MOL’s escalation history (what managers do with each order identified as suspicious), its ability to transfer learnings between stations and trust managers build in the system over time.
Prototype design considerations. There was a range of options we considered, ranging from a spreadsheet model to a clickable prototype. We chose to do a prototype that demonstrates the same order with and without a context signal to see how the choice shifts from sending automatically to escalation. We have also changed the dashboard so that managers approve the order as a whole per category with context shown alongside decisions, rather than products approved one at a time. We were also careful not to make promises that we couldn’t keep; the prototype is just the current application with an additional feature.
An extract of my contribution
I took on the business model and the evaluation, and I also designed the AI dashboard that became the face of our prototype.
Business model and defensibility. After the pivot, I worked on how our narrow context layer changes value creation and capture. We were no longer selling a forecasting engine. We were making one decision, auto-send or escalate, smarter. That shifted the question from “does MOL have an AI that orders stock?” (a commodity) to “what can MOL own that a vendor cannot copy?” My answer was the compounding asset: patterns that transfer across stations, the fact that no single complementor sees the full picture of POS data, forecast confidence, sensor feeds and manager decisions, and the trust managers build in the system over months, which works as a switching cost.
The dashboard. I designed the dashboard around how a manager actually works. Instead of approving products one by one, the manager sees orders grouped by type (for example, one order for all dry goods) and opens an order to see every product, the amount and the recommended action. Each order carries its context, such as a supplier delay or a closed road, so the manager can approve or reject with the reasoning in front of them, and the decision history makes orders easy to audit. At product level, the dashboard simply says whether stock is fine or needs ordering, with the reason behind it.
Getting it to go live, and where we needed help. A dashboard is only convincing if it is connected to something real, and ours needed certain connections (data feeds and integrations) before it could run live. That was beyond what I could finish alone, so David stepped in and helped build them. Together we then generated a new model with the help of Gemini, which gave the dashboard something working to run on. It was a good reminder that design and integration are different skills, and that asking a teammate with the right strengths early is faster than struggling alone.
Evaluation. For evaluation I set up the test around the current fixed threshold rule as the baseline, and I wanted our benefit claims to be modest. Our demo is the existing ML-based replenishment app plus one added feature, so the honest question is how much the context layer adds on top of what the current solution already saves, not how much inventory the whole system saves.
Our collaboration and its learnings
The biggest strength of our team was that we questioned each other. One person would catch that a number no longer matched the pivot, another would push back on whether a pricing tier even made sense for an internal customer, another would ask what stops a vendor from copying us. Dividing the work by slide kept us moving, but the real quality came from the cross-checking. The hardest part was keeping everything consistent after the pivot, since every earlier section had to be reread through the new, narrower idea.
