SupplyShield

Architecture Diagram

Inspiration

Supply chains do not usually fail because of one huge problem. Sometimes it is just one delayed shipment. But that delay can affect inventory, production, suppliers, transportation, budgets, and eventually customers.

We started with a simple business scenario. A company is waiting for an important shipment of components. The shipment gets delayed by a few days. The team now has to quickly figure out how much inventory is left, how serious the stockout risk is, which suppliers can help, whether another route is available, whether the emergency purchase fits the budget, and what action should be taken first.

In a real company, those decisions can involve multiple people and systems. We wanted to see if AI agents could coordinate that process instead of making an operator manually connect all the pieces.

That idea became SupplyShield.

What it does

SupplyShield is an AI-powered supply chain resilience platform that helps teams detect disruptions and coordinate recovery.

It can identify delayed shipments, connect them with inventory exposure, calculate stockout risk, evaluate alternative suppliers and routes, check financial policies, and coordinate multiple specialized AI agents to create a recovery plan.

The platform has agents focused on inventory, shipments, suppliers, risk, finance, logistics, procurement, and a Command Agent that coordinates the overall workflow.

We also built live agent activity and audit views so an operator can see what the agents are doing instead of receiving one unexplained AI response.

The Command Center also allows an operator to give the system a natural language instruction and trigger the recovery workflow.

How we built it

We built SupplyShield as a multi-agent system using Google ADK, with FastAPI handling the backend and React/Vite powering the frontend.

The agents use deterministic tools and structured supply chain data for inventory, shipments, suppliers, routes, procurement, and financial policies.

This was important because we did not want the AI to invent business facts. The tools provide the actual data, while the agents reason over that information and coordinate the response.

The frontend was designed as an operations dashboard with views for incidents, inventory, shipments, suppliers, agents, recovery plans, procurement, finance, security, and audit information.

We deployed the backend on Google Cloud Run and the frontend on Vercel so the complete system could be accessed publicly.

Challenges we ran into

One of our biggest challenges was making the agents work together as one system instead of feeling like separate AI demos.

We also had to make sure the frontend was actually connected to the backend and not showing fake responses. During deployment we ran into CORS problems between Vercel and Cloud Run, followed by Gemini configuration and quota issues.

One particularly annoying problem was an invisible character in our environment variable name. The API key was present in Cloud Run, but the application could not find GOOGLE_API_KEY because the variable name contained a hidden UTF-8 BOM character.

We also discovered that our recovery workflow could generate enough Gemini requests to hit the free-tier request limit. Debugging these problems taught us that getting a project to work locally is only one part of building a real application.

Accomplishments that we're proud of

We are proud that SupplyShield became a working end-to-end system rather than just a dashboard mockup.

The recovery workflow actually coordinates multiple agents and uses the underlying tools and data to reason about a supply chain incident.

We are also proud of the transparency we built into the system. Operators can see agent activity, timeline events, tool calls, and audit information.

Another important accomplishment was keeping deterministic business data separate from AI reasoning. Inventory quantities, shipment information, supplier data, routes, and financial policies come from structured sources instead of being generated by the model.

We also successfully deployed the complete application and tested the autonomous recovery flow in the production environment.

What we learned

We learned that building an agentic application is much more than connecting an LLM to a prompt.

The difficult parts are making agents work with reliable tools, managing state, handling failures, enforcing policies, monitoring activity, and connecting everything together in production.

We also learned that AI should not replace the underlying business logic. In a supply chain system, the model needs reliable information and clear boundaries because a confident but incorrect recommendation can have real business consequences.

Most importantly, we learned to design around the actual person using the system. An operations team needs more than an AI-generated answer. They need evidence, alternatives, policy checks, and visibility into how the recommendation was reached.

What's next for SupplyShield

We want to connect SupplyShield to real ERP, warehouse, transportation, supplier, and logistics systems so it can work with live operational data.

We also want to improve the system's ability to learn from historical disruptions and identify patterns such as recurring supplier failures or unreliable transportation routes.

Another major direction is human-in-the-loop execution. Future versions could allow authorized operators to review and approve procurement or routing actions directly from SupplyShield.

Our long-term goal is simple: when something goes wrong in a supply chain, SupplyShield should help a team move from knowing there is a problem to having a clear, evidence-based recovery plan as quickly as possible.