Product and System Overview

Intended product

An authenticated analyst uploads CSV/data files, asks for transformation or visualization, and receives a streamed answer plus generated artifacts. The agent should use Python in an isolated microVM and resume the same thread later.

sequenceDiagram
  %%{init: {"theme":"base","themeVariables":{"primaryColor":"#1e293b","primaryTextColor":"#f8fafc","primaryBorderColor":"#38bdf8","lineColor":"#64748b","actorBackground":"#1e293b","actorBorder":"#38bdf8","actorTextColor":"#f8fafc","noteBorderColor":"#fbbf24","noteBkgColor":"#78350f","noteTextColor":"#fffbeb"}}}%%
  actor User
  participant UI as React
  participant API as Product backend
  participant Graph as LangGraph
  participant Exec as Executor
  User->>UI: Upload and ask
  UI->>API: Authenticated stream request
  API->>Graph: Invoke thread
  Graph->>Exec: Execute generated code
  Exec-->>Graph: stdout, files, artifacts
  Graph-->>API: tokens and events
  API-->>UI: SSE
  UI-->>User: report and previews

Architecture status

The executor is a working control-plane component. The product workflow is described in the plan but not yet evidenced by a checked-in Python backend or graph. This distinction is the most important onboarding fact.

Product decisions

The plan favors one main analyst agent, no remote subagents initially, Postgres for both product metadata and LangGraph checkpoints, one MinIO bucket with thread prefixes, and Redis only if rate limiting, locks, fanout, or external queues become necessary.