I drove the agentic-AI capability on top of the ML platform for demand-planning analysts at a global semiconductor company: a SaaS platform that plans billions in annual GPU and CPU revenue.
Confidentiality note. Proprietary figures are withheld. Screens, data and metrics shown here are sanitized recreations built for this portfolio, directionally accurate but not the client's actual numbers.
| Level | Weekly | Monthly |
|---|---|---|
| Enterprise | 92% | 95% |
| Business unit | 87% | 91% |
| Channel | 81% | 88% |
| Distributor | 74% | 83% |
| Hyperscaler · spiky | 61% | 79% |
A designed view of the system I led: messy multi-source demand reconciled into a forecast at every level and horizon, an optimizer that trades off revenue, margin and service level under capacity constraints, and a plan written back where analysts work. The hard part was never the chat, it was the spiky, high-variability customers and keeping every level honest.
Planning a semiconductor portfolio means forecasting demand across GPU and CPU lines and then allocating scarce wafer capacity against it, every week, at the scale of billions in revenue. The catch is that "demand" isn't one number. It has to be forecast at every level, enterprise, business unit, sales channel, and distributor, and then propagated downstream to the end customers a distributor actually resells to. Each level is planned on its own and still has to add up.
I led the work to deliver this as a full SaaS platform on C3's agentic stack, where a planner could ask for a forecast, a what-if, or a reallocation and get a real answer with the numbers, and the reasoning, behind it.
The demo is a calm front end over a genuinely messy problem. The data arrived dirty and fragmented, spread across more than ten systems, needing heavy joins before a model could see a clean signal. Demand is driven by both internal variables (bookings, backlog, pricing, lead times) and exogenous ones (macro cycles, market and seasonality), and they don't move together.
The sharpest problem was variability. A few very large customers, hyperscalers like the big cloud players, buy in lumps: a massive bulk order one month, near silence the next. A smooth model misses exactly the spikes that matter most. And accuracy can't be a single headline figure: it has to hold up at weekly and monthly horizons and at every level of the hierarchy, because a different planner trusts a different cell of that table.
I owned this capability end to end and led a team of engineers, data scientists and architects to ship it as a full-stack SaaS application. Forecasting ran on regression and time-series models tuned for spiky, intermittent demand; the conversation on the OpenAI API; the app on React over Snowflake. But a forecast is only half the job, on top of it sits an optimization layer in Gurobi that turns demand into a buildable plan, trading off planning targets, revenue, service level and margin under hard capacity and commitment constraints.
My job was the strategy and the delivery: what to build, in what order, and how to make planners trust it enough to run on it, level by level, horizon by horizon.
The result was a planning workflow that analysts actually adopted, with measurably better forecasts, even on the spiky accounts, and far less capital tied up in stranded inventory.