Building the intelligence layer for retail teams managing real inventory decisions.

At HeySynth, forecasts lived inside a wider retail operating system. Operators were not asking for a beautiful prediction chart in isolation; they needed decisions they could use for inventory planning, replenishment, channel strategy, and day-to-day exception handling.

That made the engineering problem bigger than model accuracy. A single SKU could behave differently across Credo, Etsy, Sephora, Target, Shopify, or wholesale channels. Some products had enough history for richer model paths. Others had sparse or noisy data where a confident-looking forecast could quietly become dangerous.

The product needed an intelligence layer that could adapt to those realities while still giving operators clear controls and predictable system behavior.

Early forecasting and agent workflows carried the usual production-AI risks: brittle model paths, inconsistent data imports, long-running jobs with unclear status, and AI responses that could drift away from grounded operational context.

For a planning team, those issues compound quickly. If a forecast import fails silently, a dashboard can mislead. If an agent leaks internal tool traces, trust drops. If every SKU goes through the same model strategy, products with thin history get treated like products with strong signal.

The challenge was to design around real-world mess: variable data quality, asynchronous processing, multiple services, and frontend workflows where the user still needed to understand what changed and why.

My first principle was that one model path would not be enough. Products with different history depth should not be forced into the same forecasting strategy, so the forecasting layer needed safer fallback behavior and model routing based on data availability.

The second principle was that operators needed forecast controls inside the product. If a business user wants a conservative posture for one retail channel, an aggressive assumption for another, or a temporary override during a planning window, that should be represented as a workflow, not an engineering ticket.

The third principle was that AI work should not block the interface. Spreadsheet ingestion, AI-assisted extraction, and forecast processing were better handled as asynchronous cloud workers with validation gates, runtime checks, and realtime completion or error events.

Flow represents the product direction I cared about most: AI that watches operations, summarizes what changed, and helps teams decide what needs attention today.

The screen is intentionally operational. It groups signals by urgency, shows refresh context, separates critical issues from review items, and turns stockout risk into a visible business consequence instead of a hidden model output.

This matters because production AI has to meet users inside their actual workflow. A forecast is only useful if it becomes an action at the right time, with enough context for a team to trust it.

Ask Synth was the conversational interface for operators who needed to ask planning questions in plain language. The challenge was not to make a chatbot; it was to make the assistant useful against real retail context.

A user could ask for out-of-stock risks, projected revenue loss, impacted SKUs, or store-level breakdowns. The response needed to feel like a report an operator could act on, while the system still guarded against unsupported claims and internal tool leakage.

My frontend and agent work sat at that boundary: message rendering, prompt/task flow, model output cleanup, agent mode behavior, and UI states that made the assistant feel like part of the product rather than a bolted-on prompt box.

Once operators ask the same high-value questions repeatedly, the product should not force them to start from scratch every time. Playbook turned recurring tasks into reusable runs that could be tracked, reviewed, and improved.

This added another layer to the intelligence system: not just ask and answer, but configure, run, measure, and reuse. It also made agent workflows more productized, because successful prompts and analyses could become repeatable operational rituals.

For me, this was another proof point that the work was fullstack AI product engineering. The UI, API contracts, run state, output rendering, and agent behavior had to cooperate.

Forecast Mode is a good example of the system becoming tangible. The UI is not just a settings table; it reflects backend contracts, validation rules, business risk posture, channel-specific behavior, and frontend interaction design working together.

At the SKU level, the problem becomes even more concrete. A planner can inspect and adjust behavior across product rows and sales channels, with time limits and revert behavior represented directly in the workflow.

The upload and forecast surfaces added the other side of the story: bringing messy planning data into the system, processing it safely through worker jobs, and turning it into dashboard states operators could work with.

This work moved forecasting and agent workflows closer to production reality: safer fallbacks, cleaner contracts, better async processing, stronger runtime behavior, and frontend surfaces that made AI decisions easier for operators to act on.

The implementation evidence is strong: the work spans forecasting services, Forecast Mode APIs, cloud-style worker queues, MLOps reliability paths, agent orchestration, and product UI over several months of contribution history.

For a recruiter or hiring team, the signal is ownership. I was not only building UI screens or isolated models. I was working through the messy middle where AI systems become usable products.