Sentinel

Input
Main dashboard
Cockrochdb Cloud
AWS Cloud

Inspiration

It usually takes 36 to 48 hours for the market to actually react to a supply chain shock like a port closure, a sanctions announcement, or an export ban. By the time prices move and news headlines catch up, the damage to a shipment already in transit is done. We kept coming back to one question: what if a procurement team could see that shock coming while it was still just a signal buried in shipping data, sanctions lists, and weather feeds, instead of waiting for it to become a headline?

We also noticed that almost every existing tool in this space treats "supply chain" as a shipping problem. In reality, global trade doesn't move by sea alone. It moves by sea, air, road, and rail, often across the same route in a single shipment. A tool that only watches ports misses half the risk. That gap became the seed for Sentinel: a system that treats every mode of transport, not just maritime routes, as part of one connected risk picture.

What it does

Sentinel takes a shipment plan, origin, destination, transport mode, budget, timeline, and commodity, and runs it through five specialized AI agents that work together like a war room:

Geopolitical Intelligence checks the real-time risk status (safe, tension, unsafe) of every stop on the route, across land, sea, and air legs alike.
Future Scenario Simulator predicts 2 to 3 realistic disruption scenarios, each with a probability, delay estimate, and cost impact.
Route Optimization proposes safer or cheaper alternate routes that still respect mandatory checkpoints, budget, and timeline, regardless of transport mode.
Decision Advisor fuses the first three agents into one clear call: Proceed, Caution, Wait, or Use Alternate Route.
Procurement Advisor recommends better markets and suppliers for the commodity given current conditions.

One API call fires all five agents and returns a single combined decision, grounded in real external data (live news, sanctions lists, vessel tracking, weather, and energy prices) rather than a model's own guesswork.

How we built it

The agent layer

All five agents run on Groq's compound-mini model for fast reasoning with built-in web search and code execution, chosen specifically to stay on a separate free-tier quota so a hackathon demo doesn't get rate-limited mid-run. Agents 1 to 3 run concurrently, feed into Agent 4, and Agent 5 runs last, ensuring every downstream decision is grounded in facts the earlier agents actually confirmed rather than assumptions.

The grounding layer

Instead of trusting an LLM's own web search alone, we built a data grounding layer from five real, mostly free external sources: GDELT for near real-time global news, the US Treasury's OFAC sanctions list, AISStream for live vessel tracking near chokepoints, Open-Meteo for weather risk, and the EIA for real commodity price anchoring. Every client fails soft, so a missing key or a dead API never crashes an agent, it just quietly returns a neutral result instead.

Where CockroachDB became the heart of the system

This is the part we're most proud of. Early versions of Sentinel had memory that lived only inside a single request. The moment that request ended, every insight the agents produced disappeared. That's fine for a toy demo, but it's the opposite of how a real crisis response system should behave.

We rebuilt Sentinel's memory around CockroachDB, and used it in three distinct ways that go beyond simple storage:

Managed MCP Server as living memory. Each agent connects to CockroachDB Cloud through the managed MCP endpoint. Agent 1 doesn't just write its risk verdict, it reads back the last verdict for the same destination if one exists within a freshness window, so Sentinel stops re-querying five external APIs cold for a stop it already assessed recently. The orchestrator also writes a live shipment_runs row the instant a request starts and updates it as each agent finishes, turning what used to be a black box into a system you can actually watch think.
Distributed vector search as institutional memory. We embedded 20 real historical disruption events, including the January 2022 Indonesia coal export ban, directly into CockroachDB using its native vector columns. Before Agent 2 predicts a new scenario, it performs a similarity search against those embeddings and pulls in the closest historical precedent as grounding context. This closes a loop that's usually split across two separate systems: operational data (what's happening right now) and semantic memory (what happened last time something like this occurred), living together in one consistent database.
CockroachDB's open-source Agent Skills guided our schema and indexing decisions for route_intelligence, shipment_runs, and disruption_embeddings as the dataset grew during development, so the database stays fast without hand-rolled migration scripts.

The result is a memory layer that behaves less like a cache and more like a colleague who remembers the last crisis and won't let a decision stall just because a service hiccupped.

Where AWS became the execution backbone

Every agent, plus the orchestrator, runs as its own AWS Lambda function. Agents 1 to 3 are invoked concurrently through async calls, Agent 4 and Agent 5 chain afterward, giving Sentinel serverless, pay-per-decision execution instead of one always-on server absorbing every request. Amazon Bedrock generates the embeddings that feed CockroachDB's vector columns, and doubles as a fallback foundation model if the Groq free tier gets rate-limited mid-demo. Amazon S3 archives the raw grounding artifacts pulled from GDELT, AISStream, and EIA for every single run, so every decision Sentinel makes has an attached, retrievable evidence bundle, not just a black-box output.

The frontend

A geopolitical intelligence dashboard built with TanStack Start, React, Tailwind, and Radix UI, with map-based visualization and dedicated views for each agent, so a procurement team can see the reasoning, not just the recommendation.

Challenges we ran into

Keeping five agents fast without hitting free-tier limits. Running Agents 1 to 3 truly in parallel while respecting Groq's rate limits meant carefully staggering calls rather than firing them all at once, without losing the speed benefit of concurrency.
Making memory durable without making it slow. Adding a persistence layer to a real-time decision pipeline risks turning every agent call into a database bottleneck. Using CockroachDB's MCP server with a freshness-windowed read pattern let us cache smartly instead of either always hitting external APIs cold or serving stale risk data.
Grounding without over-trusting any one source. Sanctions lists, vessel data, and weather feeds don't always agree, and any one of them can go down independently. Building every grounding client to fail soft, rather than fail loud, took more care than the actual "happy path" logic.
Designing for every mode of transport, not just shipping. It's tempting to default every architectural decision toward "ports and vessels." We had to keep pulling the design back toward being mode-agnostic, so a route that mixes air freight and trucking gets evaluated with the same rigor as a purely maritime one.

Accomplishments that we're proud of

A working end-to-end pipeline where a single API call produces a grounded, five-agent decision in about 4.2 hours of end-to-end signal-to-recommendation time on average across our back-test.
Back-testing against the January 2022 Indonesia coal export ban, where Sentinel would have flagged the disruption roughly 6 hours after the earliest signals appeared, versus 36 to 48 hours for the market to visibly react, and predicted an 18 to 22 percent price spike against an actual ~20 percent move.
Across a wider 20-event historical back-test, now fully embedded into CockroachDB's vector store, an average 28-hour earlier detection lead time, 9.4 percent mean absolute percentage error on price forecasts, and 90 percent directional accuracy.
Turning CockroachDB from "a database we write to" into an actual second brain for the system, live orchestration state, cached verdicts, and vector-searchable institutional memory, all in one consistently available cluster.
A fully serverless AWS execution model where every agent scales and fails independently, instead of one monolithic process being a single point of failure for a five-agent decision.

What we learned

We went in thinking of CockroachDB as "just Postgres that doesn't go down," and came out understanding it as a genuine agentic memory substrate: operational state, cached results, and vector-searchable history can all live in one place with one consistency model, instead of stitching together Redis, a vector database, and a Postgres instance separately. We also learned that grounding matters more than model choice. A smaller, faster model with real news, sanctions, vessel, weather, and price data behind it consistently outperformed our earlier attempts that leaned purely on an LLM's own web search. And we learned, the hard way, that "supply chain risk" is a much bigger and more interesting problem the moment you stop assuming everything moves by sea.

What's next for Sentinel

Extending mode-specific risk modeling further, so rail congestion, trucking border delays, and air freight capacity constraints get the same depth of signal that maritime routes currently get.
Expanding the historical back-test set well beyond 20 events, growing CockroachDB's vector store into a genuinely comprehensive disruption memory.
Adding organization-level accounts so procurement teams can track multiple live shipments at once, each with its own CockroachDB-backed decision history.
Real-time alerting, so a shift in a route's risk status pushes a notification instead of waiting for the next request.
Deeper integration with customs and tariff data, so Sentinel's recommendations account for landed cost, not just transit risk.