Lab Z Working Papers · working
The crew as an owned artifact
Why multi-agent value should live in versioned YAML and loadable packages — not in chat threads or framework graphs.
Abstract
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.
This paper states that thesis carefully, distinguishes it from adjacent markets, and lists claims we will test as public experiments rather than marketing assertions.
1. The unit of work
A crew is mostly YAML: agent personas, tool ids, delegation edges, answer modes, and output-composition hints. Ownership here 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.
2. Adjacent markets and structural limits
| 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 correct when the agent system is your core platform. 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.
3. 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.
Automation gravity. Deterministic workflow tools 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.
4. Claims under test
We treat the following as experimental claims, not settled facts:
- Authoring latency. A dense-seed CrewDefine interview can produce a loadable domain crew in minutes, not days. (WP-02 reports one timed run.)
- Reuse beats re-prompting. Follow-up questions on a loaded crew are operationally cheaper than rebuilding a generic chat each time.
- Traces change trust. Operators and stakeholders treat runs differently when the execution graph shows which agents and tools fired.
- Contracts beat tone. Answer modes and output composition reduce “prompt forking” as the way to control verbosity and evidence shape.
- Crews are the contribution surface. Third parties can fork a crew package more easily than they can patch a runtime.
Each claim needs public reproduction, not a private demo. That is the point of shipping ./scripts/demo.sh, a crew catalog, and timed field notes.
5. What this paper is not
It is not a benchmark suite. It is not a claim that crews outperform human experts. It is not a framework comparison scoreboard. It is a positioning document for an open experiment: can a small lab make owned multi-agent teams a practical product artifact?
Related: Where Lab Z fits · WP-02: Timed domain crew · Getting started
Lab Z Working Paper 01 · August 2026 · status: working