Bring your data into Zero

The problem

A crew without trustworthy data invents numbers. DataMaker creates realistic tables; pgLens lets you see them; Zero is where people ask questions. The missing piece is a clean handoff of datasets into workspace context.

How Zero reads data today

Zero does not keep a live DB connection per chat. Agents see:

1. Organization files — uploaded documents indexed for search / knowledge tools
2. Message attachments — per-query files
3. Structured blocks in answers — [DATA_START]…[DATA_END] tables rendered in the Data tab
4. Custom plugin tools — Python tools in tools/ that can fetch from your APIs or files

So “loading data into Zero” means getting rows into one of those channels.

Path A — DataMaker → workspace files (ship now)

Best default for demos and internal crews.

1. In DataMaker, generate a dataset and export JSON (array of tables or row objects).
2. Optionally reshape to a Zero-friendly table payload:

{
  "label": "Weekly meals",
  "type": "table",
  "value": [
    { "day": "Mon", "protein": "tempeh", "cost": 12.5 }
  ]
}

3. In Zero, open the organization → upload the JSON (and a short README describing grain/units).
4. Ask the crew questions that require those fields. Specialists should hit knowledge/file search.
5. Instruct the synthesizer (via CrewDefine output_composition.tables) to echo key tables with [DATA_START] so the Data tab stays honest.

Tip: Keep files small and labeled. Prefer one table per file over a megablob.

Path B — pgLens → export → Zero (ship now)

Use when the source of truth is already Postgres/SQLite.

1. Connect in pgLens; confirm schema and relationships.
2. Export the slice you care about (CSV/JSON from your query workflow, or dump a view).
3. Upload into the Zero org as in Path A.
4. Keep pgLens open beside chat for humans verifying claims the crew makes.

pgLens stays the inspector; Zero stays the reasoner.

Path C — Plugin tool (best for recurring datasets)

When a dataset updates often, don’t re-upload manually.

1. In CrewDefine, record_custom_tool something like query_meal_catalog.
2. Implement the stub under tools/ to read from disk, S3, or a DB URL.
3. Attach it to the specialist that needs it.
4. Load the crew into Zero — the tool auto-registers from the plugins dir.

This is how DataMaker/pgLens become live inputs instead of static uploads.

Path D — Where we’re headed

Useful productizations (not all built yet):

Idea	Why
load-data.sh / org ingest API for DataMaker exports	One command → indexed workspace tables
First-class “Datasets” tab in Zero	Browse grain/schema without leaving chat
Read-only SQL tool gated by org secrets	pgLens connection string → agent queries with audit
CrewDefine archetype “data-backed crew”	Interview asks for dataset paths and wires tools

Until those land, Path A + C is the trusted story: generate or inspect elsewhere, load files or a plugin into Zero, keep composition honest.

Suggested demo narrative

1. DataMaker: generate a 4-week meal + cost table
2. pgLens: open the SQLite/Postgres copy, show relationships
3. Zero: dinner-planning crew loaded; upload the JSON
4. Ask: “Build a week under $300 with non-chicken proteins”
5. Point at the Agent run graph + Data tab as proof the crew used the table

That sequence sells the lab, not a single app.