suppl.ai

When a supply chain actually breaks, the people in charge of fixing it open six browser tabs. ERP. TMS. Slack. Email. Spreadsheet. Phone. They spend the next five hours finding out which of their containers are stuck, what that costs, and who to call. By the time they have an answer, a competitor already booked the backup capacity. The Strait of Hormuz is blocked as we write this. The Red Sea was blocked last spring. A typhoon hit Shenzhen before that. These shocks keep arriving, and nobody has built a tool that makes the first hour of a disruption bearable.

What we built

suppl.ai is an agentic war room. Three Python agents run continuously on three separate Dedalus VMs and coordinate through a Postgres event bus. Scout watches the world: news, weather, customs/policy bulletins, shipping logistics feeds, macro signals. Analyst wakes up on each new disruption and runs Gemini Pro in a function-calling loop across seven parameterized read tools against our Postgres inventory. It produces a dollar exposure figure, the list of affected shipments, and a reasoning trace for every decision. Lastly, Strategist drafts mitigations. It reroutes, alternates suppliers, and handles customer communications. A Next.js dashboard sits on top of all of it, so a human can approve or reject each mitigation in one click.

Inspiration

We wanted to build something that was not a chatbot. There is no shortage of AI assistants, and no shortage of supply chain software. Neither of those things helps the person whose warehouse just lost power. The constraint we kept returning to: if the logistics manager has to type a prompt, we have already lost. The tool has to do the first half of the work before they open it. Operator cockpits already exist for traders, pilots, and oncall engineers. None exist for supply chain managers, who run a sizeable chunk of the economy from their phones and inbox. That felt like an obvious gap.

How we built it

We built with a three-agent partition with postgres acting as the "nervous system", and Next.js and react on the front.

Agents are async Python processes. Each subscribes to Postgres channels via LISTEN/NOTIFY and writes back using ON CONFLICT DO NOTHING or content-hash deduplication, so replays are safe.
LLMs: Gemini Flash handles Scout's high-volume classification, Gemini Pro handles Analyst reasoning and Strategist drafting. Every structured output is constrained by a Pydantic response schema. Invalid output triggers one retry with the validation error appended, then falls back to a rules-based template keyed on disruption category.
SQL safety: The Analyst never writes free-form SQL. It picks from seven parameterized tools, shipments_touching_region, purchase_orders_for_skus, customers_by_po, exposure_aggregate, and a few more. Defense in depth: any synthesized SQL string gets filtered by sql_guard, which rejects anything that isn't a single SELECT at the token level. Twenty-two tests cover it.
Strategist actions run exclusively through OpenClaw. Supplier lookup, shipment status flips, audit log inserts, draft-comms writes. This is what makes the "Approve" click do real work: state changes in the database, and they're traceable.
Frontend: Next.js 15 with the App Router. TanStack Query for server state, Zustand for client state, types generated directly from FastAPI's OpenAPI schema so the front and back can't silently drift. The war room includes an interactive globe built on react-globe.gl that renders every active lane, colors it by transport mode, and animates a dashed flow along blocked routes.

What we learned

Hackathons are hard

Challenges we faced

A lot of the technologies we chose to work with were new to us, and it was our first time interacting with them on a real project. We were also very limited by api access, especially since a major component of our project involves data ingestion from multiple sources with limited free api access.