Timed domain crew: Business Coach in about seven minutes

Abstract

Wall-clock measurements from a single local session (20 Aug 2026): author a crew in CrewDefine, load it into Zero, ask a coaching question, then time follow-ups on the same thread.

Scope: founder / operator business coaching (seed–Series B B2B SaaS and services). Environment: CrewDefine CLI + Zero via Docker Compose on localhost. With Zero already running, authoring through first useful answer was about 7 minutes. Install and image pull are out of scope.

The timings matter because they are cheap enough to treat the crew as a product artifact — not a one-off prompt. What you get after those minutes is a reusable division of labor, domain tools, and a UI that operators can share. Broader framing: WP-01 and Where Lab Z fits.

A narrative field note with screenshots lives at Case study: business coaching crew. This paper is the reproducible protocol version.

1. Hypothesis

If crew authoring and first useful answer can be completed in low single-digit minutes (given a running Zero and a dense seed), then the crew package is cheap enough to treat as a shippable product unit — not a research project.

Secondary claim: follow-ups on the same loaded crew are materially faster than cold generic chats that re-derive roles each time.

2. Protocol

1. Zero already up via Docker Compose (localhost:3000 / :3001).
2. Dense --seed brief in CrewDefine specifying roster, built-in tools, and three custom tools.
3. Interview model: Claude (claude-sonnet-4-6).
4. Validate with crewdefine validate.
5. Load via ./scripts/load-crew.sh (or select the bundled copy with ./scripts/demo.sh business-coaching-crew).
6. Ask a seed-stage SaaS founder vignette in summary mode; measure SSE wall clock.
7. Two follow-ups on the same thread in light mode.

Out of scope: cold install, image pull, account creation UX, scored coaching quality.

3. Results

Authoring → first useful answer: ~7 minutes with Zero already up.

Observed on first question: 6 agents · 23 tools on the live execution graph.

4. Interpretation

• Dense seeds dominate authoring time; sparse interviews will be slower.
• Follow-up latency (27–85s) is the operational number that matters for day-to-day use.
• Provider quirks are part of the experiment: first attempts under Gemini failed with a tool-call thought_signature error; the same prompts succeeded on OpenAI. Timings must name the provider.
• The experiment supports workflow cheapness, not advice quality.

Consistency mechanisms (roles, tools, modes, traces) change the failure mode: instead of an eloquent monologue that silently skipped unit economics, you get a roster that is supposed to run diagnostics, call tools, cite sources, and only then synthesize. When something is wrong, the graph shows where.

5. Limits

• n = 1 timed session.
• Does not include cold install.
• Custom KPI tables are coaching heuristics, not audited market data.
• Not a scored coaching-quality study.

6. Reproduction

# Zero checkout — Business Coach is bundled
cp .env.example .env   # GEMINI_API_KEY and/or OPENAI_API_KEY
./scripts/demo.sh business-coaching-crew
# http://localhost:3000 — crew badge: Business Coach

Canonical package also in CrewDefine: crews/business-coaching-crew/. Timing scripts used for the original note: CrewDefine/scripts/case_study_*.py.

Domain-specific configuration and integration are available through implementation services. Maintained reference configurations are listed in the crew catalog.

Lab Z Working Paper 02 · August 2026 · status: working · local Docker · Claude (authoring), Gemini/OpenAI (runtime)