A map of the Lab Z stack
The technologies we actually touch across CrewDefine, Zero, DataMaker, and pgLens — from YAML crews and multi-agent runtimes to FastAPI, React, Postgres, and synthetic data.
Lab Z is easy to misread as “another AI chat product.” Under the hood it is a small constellation of tools that share one idea: a crew — a versioned multi-agent team — should be an owned artifact, runnable by people who never open an orchestration notebook. This note is a plain map of the technologies that constellation sits on. Not a pitch. A field inventory.
If you want the market framing first, read Where Lab Z fits. If you want to run something tonight, start with Getting started.
The unit of work: crews, not prompts
Everything else hangs off this.
A crew is mostly YAML: agent personas, tool ids, delegation edges, answer modes, and output-composition hints. CrewDefine authors and validates that package; Zero loads it. Validation is schema-first (Pydantic and Zero’s loader expectations), including graph sanity checks so a director cannot delegate to a ghost.
Why YAML instead of a vendor project UI? Inspectability, git history, and the ability to swap crews without rebuilding the app. The product is the roster, not the chat box.
Authoring: conversation constrained by tools
CrewDefine is a Python CLI. The interview uses an LLM (typically Anthropic Claude) but only through a constrained tool surface — ask, record agent, record custom tool, finalize. That keeps free-form generation from inventing an un-loadable crew.
Custom tools land as Python stubs you implement later. Built-in tool catalogs (search, documents, knowledge base, and kin) are part of the interview vocabulary so the YAML references ids Zero already understands.
Authoring stack in one line: Python + LLM tools + YAML + schema validation.
Runtime: FastAPI, React, and a live graph
Zero is the product surface for crews. The API is FastAPI; the UI is React. Chat streams over SSE so you see specialists and tools appear on a live execution graph instead of waiting for a monologue.
Around that core:
- Workspaces / organizations — shared files agents can search; multi-user durability rather than a disposable CLI session
- Answer modes — verbosity and shape as product policy from
crew.yaml, not prompt forking - Rich answer tabs — summary, data tables, visualizations, references when the synthesizer emits structured blocks
- Crew loading —
load-crew.sh/AGENT_CONFIG_DIRso the roster is swappable - Local ops — Docker (and Node) for the usual “UI + API up” path; Gemini and/or OpenAI keys for the model layer, with rate-limit fallback when free-tier RPM collapses mid-run
Runtime stack in one line: FastAPI + React + SSE + Docker + multi-provider LLMs + file-backed workspace context.
Models as a substrate, not the brand
We do not ship a model. We sit on several:
| Layer | Typical providers | Job |
|---|---|---|
| Crew interview | Anthropic (Claude) | Structured authoring under tool constraints |
| Crew execution | Gemini, OpenAI | Director / specialists / synthesizer turns |
| Synthetic text (DataMaker) | Whatever the generator configures | Language fields only; numbers stay deterministic |
The interesting engineering is routing, fallback, and contracts — not loyalty to a single vendor API.
Data adjacent: synthesis and inspection
Crews that cannot ground claims invent them. Two supporting tools keep the data story honest.
DataMaker (also shipped as DataScribe) is spec-driven synthetic data: reproducible generators for ids, numerics, and time series; LLMs only where language belongs. Export is usually JSON you upload into a Zero organization so specialists cite tables instead of improvising them.
pgLens is a lightweight explorer for PostgreSQL and SQLite — schema, relationships, typed rows. It answers “what does this data actually look like?” before or beside a Zero run. Export CSV/JSON into workspace files when you need a slice inside chat; keep pgLens open when a human must verify a claim.
Neither replaces a warehouse or BI. They sit in the handoff path described in Bring your data into Zero: inspect or synthesize elsewhere, reason in Zero with that context loaded.
Data stack in one line: synthetic specs + Postgres/SQLite inspection + file/JSON handoff into agent context.
How the pieces touch
CrewDefine ──YAML crew──▶ Zero (FastAPI / React / SSE)
▲
DataMaker ──JSON──┐ │ workspace files / plugins
pgLens ──export───┴───────────┘
- CrewDefine → Zero: validated crew directory becomes the active roster.
- DataMaker / pgLens → Zero: datasets become searchable org files, attachments, plugin-fetched rows, or structured
[DATA_…]blocks in answers. - Humans: author once, operate many times; the execution graph is how you audit that the system behaved like the crew you claimed to ship.
What we deliberately do not center
- A single closed chat product with unfalsifiable roles
- An agent framework as the deliverable (we are closer to a small expert-system product with a loadable roster)
- Live per-chat warehouse connections as the default (today: files, attachments, plugins)
- Dashboard replacement — agents narrating without tables are worse than tables without narrative
Why publish the map
Search and evaluation both need nouns: multi-agent crews, YAML agent configuration, FastAPI streaming chat, React execution traces, synthetic data generation, Postgres schema exploration, SQLite browsing, workspace knowledge tools. Those are the technologies Lab Z actually touches. The suite is the composition — CrewDefine designs the team; Zero runs it; DataMaker and pgLens keep the surrounding data legible enough to check.
From here: Apps, Crews, Guides, Papers, or the notes index.
Field note — Lab Z, August 2026.