Prometheus

Give it a problem. It builds the company, attacks it with 5 AI critics, repairs every flaw, and ships the survivor to a live URL — in minutes

Comment

Prometheus — The Adversarial Venture Engine

Inspiration

The idea for Prometheus was born from a single frustrating observation:

Every AI tool that exists today is a yes-man.

You ask Copilot to write an authentication system — it writes one. You ask Bolt to build a SaaS app — it builds one. You ask any AI coding tool to generate an API — it generates one. In every case, the AI does exactly what you asked, hands you the output, and walks away. It never asks: "But is this actually good? Is it secure? Will it scale? Will it make money? Is it even legal?"

We kept thinking about how real startups die. They don't die because the founder didn't have an idea. They don't die because nobody wrote the code. They die because nobody attacked the idea hard enough before it hit reality. A security breach at month 6. A GDPR fine at month 9. A pricing model where lifetime value was always less than acquisition cost. A database with no indexes that collapses under the first real load spike. These are not exotic failure modes — they are the standard ones. And every single one of them could have been caught before a single user signed up.

We asked ourselves a question nobody else was asking: What if the AI didn't just build the company — what if it also tried to destroy it?

That question became Prometheus.

The name comes from Greek mythology. Prometheus stole fire from the gods and gave it to humanity. The fire didn't just illuminate — it also burned. We liked the duality. Prometheus the system doesn't just give you a product. It puts that product through fire first. What survives the fire is worth shipping.

What We Learned

Building Prometheus taught us things we genuinely did not expect to learn.

1. Adversarial AI is architecturally different from assistive AI

Every AI system we had built before was a pipeline: input → process → output. Linear. Deterministic. Prometheus required something fundamentally different: a cyclic adversarial graph. The system had to loop. Build → Attack → Defend → Arbitrate → Attack again if needed. The mathematics of this termination condition is non-trivial.

If we model the survival score $S$ as a function of resolved threats $r$ over total threats $t$, with a penalty of 15 points for each unresolved critical-severity report $c$:

$$S = \max\left(0,\ \min\left(100,\ \frac{r}{t} \times 100 - 15c\right)\right)$$

The defense loop terminates when $S = 100$ or when the retry count $n$ reaches its hard limit:

$$\text{terminate if } S = 100 \text{ or } n \geq 3$$

Designing a LangGraph StateGraph that routes correctly through this condition — never deadlocking, never looping infinitely — required us to think about AI orchestration as a state machine with convergence guarantees, not just a chain of prompts.

2. Multi-agent systems fail at the seams, not at the nodes

Each individual agent — the Security Critic, the Product Critic, the Defender — works perfectly in isolation. Failures always happen at the handoffs. A kill report generated by one agent had to be parsed, classified, and acted upon by a completely different agent with zero shared memory. We learned that structured JSON contracts between agents are not optional — they are the product. The schema design for KillReport and SharedContract was more important than any single agent's prompt.

3. Speed is a feature, not an optimization

When we first built the system, a full pipeline run took 12–14 minutes. Technically correct. Practically useless for a live demo. We learned that for adversarial multi-agent systems, perceived latency directly determines whether the product feels intelligent or merely slow. Switching to Google Gemini 2.0 Flash — and running all 5 critics in parallel via asyncio.gather() — brought the full pipeline under 4 minutes. The product became dramatically more compelling the moment it became fast. Flash was the right model for this specifically: its combination of speed, long context window, and generous free tier made orchestrating 6 concurrent agents economically viable at zero cost.

4. Real-time UI is not decoration — it is the argument

We almost shipped Prometheus with a simple progress bar and a final result screen. Then we built the War Room HUD — the 3-column live interface with the survival meter, kill report feed, and combat log. The moment we ran it with the full UI, everything changed. The AI wasn't just "working" anymore — it was visible. You could watch a CRITICAL threat appear, watch the survival score drop, watch the Defender patch it, watch the score recover. The UI turned a technical system into a narrative. We learned that for adversarial AI, transparency is the demo.

How We Built It

Prometheus is built in five distinct phases, each corresponding to one stage of the pipeline.

Phase 1 — Genesis: The Blueprint Engine

The first agent receives a plain-English business problem and produces a SharedContract — a structured JSON document containing the company name, product features, database schema, API surface, pricing tiers, compliance requirements, and known risks. This is the single source of truth for everything downstream.

Every subsequent agent reads from and writes to this contract. We designed it using Pydantic v2 with strict field validation so that malformed LLM outputs would be caught immediately rather than propagating silently into the build phase.

Phase 2 — Construction: Parallel Build Agents

Four specialized sub-agents build the MVP simultaneously using asyncio.gather():

  • Frontend Agent — Generates a complete Next.js 14 TypeScript application
  • Backend Agent — Generates a FastAPI Python server with real business logic
  • Database Agent — Generates SQL migrations with realistic seed data
  • Docs Agent — Generates README, API reference, and company brief

None of these agents communicate with each other. They communicate only with the SharedContract. This architectural principle — contract as interface — is what makes parallel generation coherent and conflict-free.

Phase 3 — The Crucible: Five Critic Agents

All five critics run concurrently. Each is a specialized Gemini 2.0 Flash call with a deeply adversarial system prompt:

Agent Codename Attack Vector
Security THE BREACH Auth flaws, injection vectors, IDOR vulnerabilities
Product THE ADVOCATE UX dead ends, missing flows, empty states
Compliance THE REGULATOR GDPR, FDA, PCI-DSS, CCPA, HIPAA citation violations
Scalability THE ARCHITECT N+1 queries, missing indexes, synchronous bottlenecks
Business THE INVESTOR LTV/CAC imbalance, missing moat, GTM blind spots

Each critic outputs a structured array of KillReport objects. Kill potential is scored on a scale of $1$ to $10$:

$$\text{kill_potential} \in {1, 2, \ldots, 10},\quad 10 = \text{existential threat}$$

Phase 4 — Defense: The Autonomous Repair Loop

The Defender Agent receives all open kill reports sorted by severity and kill potential. For each report, it classifies the repair strategy into one of three paths:

  • Kill potential $\geq 7$: Patch immediately — too dangerous to challenge
  • Kill potential $4$–$6$: Patch the code or amend the contract
  • Kill potential $\leq 3$: Challenge the finding — escalate to the Arbiter

The Arbiter is a neutral judge agent that reads the original criticism alongside the Defender's counter-argument and delivers a binary verdict: ACCEPTED (report dismissed, score rises) or REJECTED (must patch, loop continues). This three-way classification makes the system reason about tradeoffs rather than blindly applying every suggested fix.

Phase 5 — Deploy: Ship the Survivor

The surviving codebase is packaged and deployed. The FastAPI backend streams every event in real time to the frontend via Server-Sent Events (SSE), updating the War Room HUD live — no polling, no page refresh.

The War Room HUD

The frontend is built in Next.js 14 with pure vanilla CSS Modules — no UI framework, no component library. The aesthetic is a military operations terminal: deep black backgrounds, tactical green text, Rajdhani/Orbitron/Share Tech Mono typography, scanline overlays, and a 3D animated particle grid rendered on HTML5 Canvas. The layout is a 3-column war room with independent scroll areas for the Pipeline Status tracker, Survival Meter, Combat Log, and Threat Intelligence (kill report) feed.

Challenges We Faced

Challenge 1: The Context Collapse Problem

The hardest technical problem was keeping multiple agents coherent across a long pipeline run. LLMs have no memory between API calls. By the time the Defender was reading kill reports generated by the Security Critic, it had no awareness of the code that the Backend Agent had written three minutes earlier.

Our solution was the SharedContract plus a generated_files dictionary — a complete, serializable representation of the entire system state passed in full to every downstream agent. Large context windows per call, but zero incoherence. The agents didn't need memory. They needed a complete briefing document. That's what we gave them.

Challenge 2: Parsing Hostile LLM Output Under Pressure

Instructing an LLM to output "ONLY raw JSON, no markdown, no explanation" works approximately 85% of the time. The remaining 15%, it adds a preamble, wraps output in code fences, or appends a trailing comment. In a 5-agent parallel attack phase, one parsing failure used to crash the entire pipeline.

We solved this with three defensive layers:

  1. Regex-based JSON extraction to strip markdown fences before parsing
  2. A retry mechanism: on parse failure, re-send with the error message embedded
  3. Graceful degradation: a critic that fails entirely returns an empty list — the pipeline continues with reports from the remaining four critics

Challenge 3: Making the Defense Loop Terminate

Early versions of the loop occasionally entered cycles. The Defender would patch a report, the Arbiter would reject the challenge, the Defender would re-patch, and the loop would continue indefinitely. We needed a termination guarantee without sacrificing repair quality.

The solution was a hard retry limit combined with a monotonic score condition. If the survival score $S$ does not strictly increase between two consecutive defense iterations:

$$S_{i+1} \leq S_i \implies \text{terminate and deploy best available version}$$

This guaranteed termination while still allowing the system to make as many genuinely useful repair passes as the convergence condition permitted.

Challenge 4: Real-Time Streaming Across the Full Pipeline

FastAPI's SSE implementation is straightforward for simple cases. Our case was not simple: a background pipeline running in one asyncio task needed to emit events to an SSE endpoint consumed by a different HTTP connection, while also updating a shared in-memory mission store readable by a third endpoint.

The solution was an asyncio.Queue per mission. The pipeline task puts events into the queue. The SSE endpoint reads from the queue and streams them to the browser. The mission store is updated as a side effect of the same emission. Three different consumers. One event source. Zero race conditions.

Challenge 5: Choosing the Right LLM for a Multi-Agent Adversarial System

Running 6–7 AI agents concurrently in a loop — building, attacking, defending, arbitrating — generates enormous token throughput. Using a heavy frontier model would have exhausted API quotas within minutes of demonstration. We evaluated options specifically for speed, context length, concurrency support, and free-tier generosity.

Google Gemini 2.0 Flash was the clear answer. Its speed made the pipeline feel live rather than slow. Its 1M token context window meant we could pass the full system state to every agent without truncation. And its free tier made the entire system run at exactly $0 — which meant we could run it dozens of times during development without financial constraint.

What's Next

Prometheus in its current form proves a new category: adversarial AI systems that verify their own output before humans have to. The immediate next steps are:

  • Domain-specific critic packs — a healthcare pack (HIPAA-focused), a fintech pack (PCI-DSS/SOX-focused), an enterprise pack (SOC2/procurement-focused)
  • Persistent mission history — teams can compare the evolution of a product across multiple Prometheus runs and track which classes of vulnerabilities recur
  • Human-in-the-loop override — let the user veto specific Arbiter verdicts before the defense loop continues
  • True CI/CD integration — run Prometheus as a gate in a pull request pipeline, not just as a standalone tool

The core insight — that AI should attack its own outputs before humans have to — is not limited to startups. It applies to any high-stakes system where the cost of undetected failure is high: medical software, financial systems, government infrastructure, autonomous vehicles. That is an enormous surface area.

Prometheus is the first working demonstration that adversarial AI verification is buildable today, by a student , in 72 hours, at zero cost.

The fire doesn't just illuminate. It burns. What survives the fire is worth shipping.

Built at Tech Builders Program Hackathon 2026. Total infrastructure cost: $0.

Built With

Share this project:

Updates

Submission history