Inspiration
Supply-chain crises rarely arrive one at a time. A canal closes, then a port strikes, then demand spikes while you're still figuring out the first problem. The teams that get it wrong usually aren't missing information, they just can't hold all of it in their heads fast enough to reason about it properly. Most "AI for this" tools don't help much either, because they give you a confident answer with no way to check it. We wanted to try the opposite: agents that actually investigate a problem and show their work, running on GPT-5.6, in a system that refuses to trust its own output until it's earned it.
What it does
The core idea is chaos engineering for decisions. Infrastructure teams deliberately inject failures to learn whether systems survive; Black Swan does the same to a proposed plan. It introduces controlled shocks such as supplier loss, demand spikes, stale evidence, or tighter budgets, then watches the swarm challenge assumptions and compare response branches. The goal is not the most optimistic answer. It is the option that still holds up when the world stops cooperating.
You describe a business issue in plain language. Black Swan asks about whatever is genuinely unclear, then puts together the smallest team of AI specialists that problem actually needs. They work inside a sandbox with no network access, so nothing they do can touch a real system. Every piece of evidence gets a status: validated if it traces back to the simulation or a source that's actually been checked, challenged if it hasn't. A person signs off on the plan before anything runs. You can watch the whole thing happen through a dashboard and a spatial office view showing which agent is doing what.
When the AI is wrong, or just unsure, that's not hidden behind a confident answer, it shows up as unresolved evidence sitting in "challenged" status until something backs it up. That's the actual safety net, not a disclaimer bolted on afterward.
The scenario we built to prove this out is the Suez Cascade: a canal closure, a port strike, and a demand surge, layered on top of each other in a deterministic simulation. You can compare Wait, Cape reroute, and Hybrid responses from the exact same starting state, so you can actually check whether the AI's reasoning holds up.
How we built it
We started with the simulation itself, no AI involved, because we wanted something the agents could be checked against rather than something they could talk their way around. Everything else went on top of that over four days, Jul 17 to 20, with Codex doing most of the actual writing:
Jul 17: got the MVP simulation running, then burned most of the day trying different spatial-office implementations before settling on the Agents SDK for narration. Jul 18: built the actual multi-agent piece, a swarm coordinator with Flow, Continuity, and Value directors as tools (PR #3), added cost limits and CI (PR #2), async persistence and memory (PR #4), and packaged it for production with regression evals(PR #6). Jul 19: added the LangGraph case workflow and the sandbox, pulled out an earlier DOM-based office once the Phaser version worked properly, and found a JSON schema bug that had been quietly breaking every research call. Jul 20: visual pass and a bunch of small UI fixes across mission control.
Stack: FastAPI and Pydantic on the backend, the OpenAI Agents SDK for bounded runtime reasoning, LangGraph checkpointed to SQLite, a Docker sandbox with no network or credentials, and a React/TypeScript frontend with both a Phaser 2D view and a Three.js 3D one, both reading off the same event stream. Codex with GPT-5.6 was used throughout the architecture, implementation, testing, debugging, and Docker packaging.
Challenges we ran into
Getting the evidence-trust logic right took longer than any of the agent prompting. It's easy to make a system that sounds confident; it's harder to make one that's honestly unsure when it should be.
We also had a bug that stayed hidden longer than it should have: a schema mismatch was silently failing every research call, and it didn't show up until we actually went looking for problems instead of just checking that the demo ran.
Partway through we had two different implementations of the case office, one DOM-based and one in Phaser. Keeping both would have meant they'd drift apart eventually, so we killed the older one even though it worked.
Cost control had to go in early. Polling the UI without any caching would burn through a budget in minutes, so single-flight execution and fingerprint-based caching went in before we added more agent capability, not after.
And once agents could execute code, sandboxing wasn't optional or a later clean up step: no network, no host mount, no credentials, dropped capabilities, non-root, hard limits on CPU, memory, and processes.
Accomplishments that we're proud of
The simulation stays authoritative no matter what the AI layer does with it. The multi-agent swarm is real tool-calling with tracing, not a single prompt dressed up as several agents. A case can be killed mid-run and pick back up from its last checkpoint. Evidence starts out unverified by default instead of trusted by default, so the system stays honest about what it doesn't know yet. And after four days of Codex making changes almost continuously, 66 backend tests and 8 frontend tests are still green.
What's next
Adapters that can corroborate evidence against real external sources instead of just simulation state, generated PDF decision packages, full parity between the 2D and 3D office views, and testing whether agents can genuinely graduate to permanent status across real completed cases, not just one demo run.
Log in or sign up for Devpost to join the conversation.