Data & AI Hackathon · San Francisco · Sept 11, 2026

Many agents.Many branches.One answer.

Parallax is a multi-agent data-analysis swarm. Give it a dataset and a question; it forks an isolated Hotdata database per hypothesis, runs analyst agents concurrently (SQL + BM25 + vector search), synthesizes one cited report, and remembers what it learned in Cognee so the next investigation starts smarter.

View on GitHub Run it in 3 commands
Parallax Mission Control during a run: status stepper and live metrics tiles on top, the lineage tree of forked databases on the left, one card per agent with its SQL and finding in the middle, and the cited report on the right.
Concurrent queries
100concurrent queriesp50 15 ms · p95 30 ms — burst across 5 forked databases
Time to first finding
1.2 stime-to-first-findingmeasured from started_at to the first agent.finding
Agents per run
2–16analyst agents per runone hypothesis each, one isolated database fork each
API keys needed for local mode
0API keys needed for local modeDuckDB forks, fake LLM, local memory — the identical code path
How it works

Fork the database per hypothesis.

One analyst, one query, one hypothesis at a time is the bottleneck. Eight agents on one shared database trip over each other. Parallax gives every agent its own snapshot, its own indexes, its own scratch tables — and merges what they find.

  1. 01

    Fork

    A root Hotdata database is created per run and the dataset loaded. The planner, primed by memory, proposes exactly N hypotheses with diverse strategies, and the root is forked once per hypothesis.

  2. 02

    Explore concurrently

    N agents run under asyncio.gather. Each loops think → SQL / BM25 / vector search → observe (up to 4 steps) on its own fork, then commits a finding with a confidence score.

  3. 03

    Synthesize

    One report with an executive summary, key findings, next questions and [branch:<id>] citations you can click to jump to the evidence — the fork and the SQL that produced it.

  4. 04

    Remember

    The question and findings are written to Cognee with node sets per dataset and per run, in the background, and recalled before the next plan so the next run starts smarter.

Product tour

Every button does something real.

Live mode badges from /api/health, SSE-driven Mission Control, a memory page backed by the Cognee graph, and read-only connection settings — secrets never touch the browser.

Launch page: hero, live mode badges, and dataset cards for SaaS customers, e-commerce orders and SF Airbnb listings.
LaunchPick a dataset (or drop a CSV), choose a suggested question, set 2–16 agents and launch the swarm.
Memory page: recall search box, stats tiles for memories, tags and backend (Cognee), and a list of recent memories with dataset and run tags.
MemoryWhat Parallax remembers across runs — recalled before every plan, scoped by dataset and run node sets.
Connections settings page: cards for Hotdata, RocketRide, Cognee and LLM with live status and the environment variable names to set.
ConnectionsLive status of each subsystem plus a copy-to-clipboard .env template. Read-only by design.
Sponsors

Built on the sponsor stack.

Each sponsor's stated criterion, verbatim, next to what Parallax actually does with it and where the code lives. Every cloud piece has a zero-key local fallback.

Hotdata

hotdata.dev ↗
Prize criterion“Build an application where multiple agents or users need to search, query, or analyze data concurrently.”
  • One root database per run, forked once per hypothesis via POST /databases/{id}/fork, so N agents query N isolated databases at the same time. The lineage tree in Mission Control is the lineage API response.
  • Search, not just SQL: a BM25 index on data and a provider-backed vector index on a data_vec copy, created lazily per branch because forks do not carry indexes.
  • Burst mode fires 10–200 concurrent reads across the forks and reports p50 / p95 / max; every query's elapsed_ms feeds the live percentiles.
backend/app/data/hotdata.py

RocketRide

rocketride.org ↗
Prize criterion“Build your project on RocketRide Cloud and deploy an AI pipeline without managing any infrastructure.”
  • Every planner, agent and synthesizer LLM call goes through pipelines/parallax-llm.pipe with the rocketride SDK: use() once with a cached token, chat() per call.
  • parallax-analyst.pipe is the deployable analyst: an agent_rocketride node controlling Claude, memory_internal, a db_hotdata tool and a tool_cognee node.
  • Point ROCKETRIDE_URI at https://api.rocketride.ai and it runs on Cloud with nothing to host; per-call fallback rocketride → anthropic → ollama never fails a run.
pipelines/parallax-analyst.pipebackend/app/llm/rocketride_llm.py

Cognee

cognee.ai ↗
Prize criterion“Build persistent memory and context for your AI agents.”
  • add → cognify → search: after each run the findings are written in a background task; before each plan they are recalled with GRAPH_COMPLETION and injected into the planner prompt.
  • Node sets per dataset and per run keep memories scoped — recalls for ecommerce_orders never surface SaaS churn facts.
  • The graph is rendered in /memory via cognee.visualize_graph(); Cognee is also a tool for the RocketRide agent, and falls back to LocalMemory with the same protocol.
backend/app/memory/cognee_memory.py

Snyk

snyk.io ↗
What runs in CI“snyk test --all-projects --severity-threshold=high and snyk code test on every push and pull request.”
  • continue-on-error, skipped gracefully when SNYK_TOKEN is absent — a missing token never blocks contributors.
  • The public badge in the README links to the report; make snyk runs the same scans locally.
  • SECURITY.md covers disclosure, the read-only SQL guard, per-branch isolation with 24 h expiry, and server-side-only secrets.
.github/workflows/ci.yml
Architecture

Next.js in front, FastAPI in the middle, forks underneath.

Parallax system architecture: Next.js Mission Control talks REST and SSE to a FastAPI orchestrator, which forks Hotdata databases, routes LLM calls through RocketRide pipelines, remembers into Cognee, with Snyk in CI and zero-key local fallbacks for every cloud piece.
  • DataEngine abstraction. One protocol — create_database, fork, load_csv, query, bm25_search, vector_search, lineage — with two implementations: HotdataEngine over HTTP and LocalEngine over DuckDB files. The orchestrator never knows which one it has.
  • Five phases, typed events. provisioning → planning → exploring → synthesizing → remember, emitting an event after every state change. Peak concurrency is measured with an in-flight counter; every query's elapsed_ms feeds p50 / p95.
  • SSE, not polling. GET /api/runs/{id}/events replays a per-run buffer then streams live, so a refresh or a shared link rebuilds the exact same Mission Control. Runs persist as JSON after every event.
  • Fallbacks everywhere. LLM chain rocketride → anthropic → ollama with per-call provider attribution; Hotdata → DuckDB; Cognee → local JSON memory; Ollama embeddings → deterministic hashed embeddings. Zero-key mode runs the identical code path.
Run it

Three commands. No accounts.

Zero-key mode runs the whole orchestrator, event stream and UI on a laptop with DuckDB forks and a fake LLM. Add keys when you want the cloud.

zsh — parallax
$ git clone https://github.com/vnmoorthy/parallax && cd parallax
$ make setup     # uv sync (backend) + pnpm install (frontend)
$ make demo      # zero keys → http://localhost:3000

Turn on the cloud

ServiceVariables
HotdataHOTDATA_API_KEY + HOTDATA_WORKSPACE_ID
RocketRide CloudROCKETRIDE_URI + ROCKETRIDE_APIKEY
AnthropicANTHROPIC_API_KEY
CogneeANTHROPIC_API_KEY + Ollama nomic-embed-text

Copy .env.example to .env and fill in any group. Every variable is optional and every subsystem resolves independently; GET /api/health and the badges in the UI show what you ended up with.