Guide
Where Lab Z fits
A sober map of adjacent markets and the problems the CrewDefine → Zero suite is actually for.
For Builders and operators evaluating the stack
Thesis
Most “AI agent” activity collapses into one of two mistakes: treating orchestration as a library problem (wire enough graphs and something useful appears), or treating it as a chat problem (put a model in a nicer box and hope roles emerge from tone).
Lab Z is built on a different unit of value: the crew — a versioned team of agents with explicit roles, tools, and output contracts — authored once, then run repeatedly by people who should not have to read the orchestration code. CrewDefine is how that artifact is designed and validated. Zero is how it is operated: workspaces, streaming execution, answer modes, and inspectable traces. DataMaker and pgLens are not the product center; they exist because crews that cannot ground claims in tables quietly invent them.
Three adjacent markets
| Category | What it optimizes | Structural limit |
|---|---|---|
| Agent frameworks | Composability for engineers | The “product” is still something you must invent: auth, UI, eval, crew lifecycle |
| Chat products | Latency to a plausible answer | Weak notion of role, weak reuse, weak evidence that work was delegated rather than improvised |
| Analytics / BI | Visibility into data | Stops at representation; composition and judgment remain human side-channels |
Lab Z overlaps each without living in any of them. Frameworks remain the right choice when the agent system is your core platform and you will fund the surrounding product. Chat products remain correct when a single thread and a document corpus are enough. BI remains correct when the deliverable is a query or a chart. The Lab Z loop is for when the deliverable is a composed decision artifact produced by a known division of labor, and when that division of labor itself should be an owned asset.
What “owned” means here
Ownership is not merely “we host the model.” It means:
- The crew definition is inspectable YAML (and optional tools), not a prompt trapped in a vendor UI.
- Loading a different crew does not require rebuilding the application — Zero swaps the active roster.
- Runtime behavior is observable: who ran, which tools fired, what the synthesizer emitted.
- Output shape is partially contractual (
answer_modes,output_composition) rather than entirely emergent.
That combination is closer to shipping a small expert system than to chatting with a generalist.
Failure modes we are trying not to inherit
Framework gravity. Teams start in CrewAI / LangGraph / AutoGen and discover that 80% of the work was productization. Traces, modes, multi-user workspaces, and “will a non-engineer trust this?” arrive late and ad hoc.
Chat gravity. Teams start in Projects / Custom GPTs and discover that multi-step specialist work becomes an unfalsifiable monologue. You cannot show a customer which competence was exercised — only a final paragraph.
Dashboard gravity. Teams expect agents to replace BI. They should not. Agents that narrate without tables are worse than dashboards that show tables without narrative. The honest architecture is tandem: inspect or synthesize data elsewhere (pgLens, DataMaker, warehouse), then reason in Zero with that context loaded.
Automation gravity. Deterministic workflow tools (n8n, Zapier, and kin) excel when the graph is known. Multi-agent crews excel when the path requires judgment, research, and synthesis. Conflating the two produces either brittle “AI steps” in a zap or crews that pretend to be CRON.
Suite use cases (problem-shaped)
Vertical advisory products
You need a domain-shaped assistant — planning, diligence, ops briefing, internal strategy — that a team can log into without learning an agent framework. CrewDefine encodes the domain’s division of labor; Zero is the surface; optional seed datasets keep demos from lying.
Grounded research packs
The question is not “write something smart” but “compose an answer that survives contact with rows.” pgLens clarifies what exists; DataMaker supplies safe synthetic stands-in; Zero’s file/plugin paths and structured data blocks keep the synthesizer honest.
Crew as a team asset
One configuration, many users, shared workspace context. Answer modes express verbosity as product policy rather than prompt forking. The live execution graph is not decoration: it is how operators and stakeholders audit that the system behaved like the crew you claimed to ship.
Pedagogy and evaluation
Teaching multi-agent systems without a visible control flow teaches theater. Zero’s traces make runs discussable; CrewDefine keeps the syllabus (the crew) in git.
From prototype to something people return to
Authoring stays cheap in CrewDefine; durability (accounts, orgs, streaming, rich tabs) already exists in Zero. The data tools keep early demos from training stakeholders to expect hallucination.
When another category is the better fit
- A single prompt over a document set — use a chat product.
- Hard SLAs over known API sequences — use automation infrastructure.
- The agent runtime is your multi-tenant platform and must be embedded deeply — start from a framework (or plan a deliberate Zero fork), not from a load script.
- Warehouse-grade analytics — stay in BI; pass summaries or extracts into Zero afterward.
One sentence, used carefully
CrewDefine designs the multi-agent team as an owned artifact; Zero runs that artifact for people; DataMaker and pgLens keep the surrounding data legible enough that the crew’s claims can be checked.
From there: Getting started, Crew catalog, Working papers, then Bring your data.
← All guides · crewdefine , zero , datascribe , pglens