What is the problem your project solves?

No software can answer "how will people react to this?"

Every launch, redesign, pricing change and policy draft is shipped into uncertainty and validated after the fact. The existing ways to reduce that uncertainty are all slow, expensive, or both:

The common structure: all four are expensive ways to ask one question, and all four require the thing to already exist.

Why it matters: the decision that kills a product is almost never the one that lacked data — it is the one where the objection existed in the population and nobody in the room held it. Teams do not lack analytics; they lack reaction before the artifact is real.

Impact: if reaction becomes a sub-two-minute query instead of a six-week procurement, pre-launch validation stops being a privilege of companies with research budgets. Every solo founder, policy writer and PM gets the objection list a focus group would have surfaced — before the code is written.

How you are solving it?

Prodly (engine name: CHORUS)

Point it at a URL, a launch brief, a pricing memo or a policy draft. It returns a simulated reaction from a calibrated synthetic population — not an essay, but a ranked list of specific objections with probabilities, plus the trajectory showing how those objections spread through the population round over round.

Core loop

seed → ontology → population → swarm rounds → propagation → objection ranking → report
           ↑                                                                     │
           └─────────── calibration update ←── observed outcome ─────────────────┘

The upward arrow is the product. Personas are fitted to observed reaction data and carry a measured calibration score; populations are versioned (us_consumer.v2.4.1) and backtestable.

What we built

• Concurrent rendered browser journeys — every persona gets an isolated Chrome session via agent-browser; sessions navigate concurrently and re-observe the rendered DOM after each transition. Route selection is personality-weighted: price-sensitive agents go to pricing, privacy advocates hunt for security pages, detail-oriented agents open docs.
• DOM → visual perception engine — each rendered screen becomes a Spatial Viewport Layout Model: above/below fold, visual hierarchy, element prominence, clutter score. Agents reason over what a human would actually see, not raw HTML.
• 30-parameter persona matrix — non-hardcoded personas sampled from trait distributions (tech literacy, patience, cynicism, privacy concern, visual noise tolerance, peer susceptibility).
• Emergent multi-agent swarm — across up to 10 rounds agents debate peers, share complaints and flip stances. Stance changes are caused by exposure to other agents, never by re-rolling. That is the line between a simulation and a survey.
• Screenshot-grounded reactions — agents receive the rendered screenshot plus its accessibility map, so an objection can cite the numbered element visible in the evidence image. Live failures never silently fall back to fixture prose.
• WhatsApp-style tester thread — the report prints every persona's screen-by-screen message as GOOD / PROBLEM / NO OPINION with a link to the annotated screenshot they were looking at. Raw reactions, not rewritten into polite "suggested fixes".
• Ratatui-style TUI — live God's-Eye node constellation, murmur feed, stance distribution bars, ranked friction points.
• 3D audience frontend — the same swarm rendered as a room of people. React + Three.js (react-three-fiber, drei) with MediaPipe face-gaze tracking. Every agent is a seat. When the swarm blocks on question_callback those seats raise their hands; calling on one walks the persona to the stage with the screenshot they were stuck on shown on their laptop. Your typed or voice-transcribed answer feeds straight back into the swarm as the owner's reply, and the next hand goes up. At the end each person floats their main concern overhead; click them to see every concern with evidence.

Architecture

Python engine (Typer CLI + Rich TUI) → FastAPI bridge (POST /api/runs, GET /api/runs/{id}) → Vite/React/Three.js frontend. Async fan-out at concurrency 40, per-round timeouts, partial failure non-fatal (a round completing at 96% is a success). A --fixture mode replays recorded responses for fully offline, deterministic demos with zero API key.

Disclosure

Built during the hackathon window. Pre-existing assets: the agent-browser driver (third-party, installed via npm) and the us_consumer.v2.4.1 population artifact, which is loaded from disk rather than trained live. Everything else — engine, swarm, perception layer, FastAPI bridge, TUI and the 3D audience app — was written here and has not been submitted to another hackathon.

Honest limitations

Calibration is measured on 5 backtest cases: enough to demonstrate the loop, not enough to claim generalisation. Populations derive from English-language public corpora and inherit that sampling bias. We have no out-of-domain accuracy number yet — the honest answer is "we don't know, and here is the loop that would tell us."

How Did You Use Claude?

Claude is the intelligence layer, end to end

There is no Prodly without Claude — every persona, reaction, cluster and report is a Claude call. We route each stage to the model whose cost/quality profile fits, via the anthropic Python SDK:

CHORUS_MODEL_ONTOLOGY=claude-sonnet-5
CHORUS_MODEL_PERSONA=claude-haiku-4-5-20251001
CHORUS_MODEL_CLUSTER=claude-sonnet-5
CHORUS_MODEL_REPORT=claude-opus-5
CHORUS_MODEL_INTERROGATE=claude-sonnet-5

Multimodal grounding. Persona calls are not text-only. Each agent receives the rendered screenshot of the screen it is on plus the accessibility map, so Claude's vision is what produces objections that cite a specific visible element rather than generic UX platitudes.

Swarm dynamics. In rounds 2+ each agent's prompt carries a seeded sample of its neighbours' prior reactions. Claude decides — in character, under its 30 trait parameters — whether to hold or flip its stance. The emergent propagation curve is a product of those individual Claude judgments, not of any hand-written rule.

Engineering around it. Async fan-out at concurrency 40, per-round timeouts, ≥90% completion threshold, and a record/replay fixture layer that captures live Claude responses so the demo runs deterministically offline.

Claude Code built it. The whole repo was developed with Claude Code — PRD, architecture, data contracts and implementation plan live in backend/docs/ and were written and executed against inside the 5-hour build window.

What is the deployed URL for this project?

Not yet deployed — draft submission, URL to be added before publish.