# Joe Schmidt IV: Avoiding Death On The Yellow Brick Road Status: deepened milieu note ## Source - Date captured: 2026-06-18 - Source type: `x_longform` - Source title: `Avoiding Death on the Yellow Brick Road` - Source URL: - Source show / channel / publication: X / Joe Schmidt IV - Platform: X - Local source file: `external_material/archive/processed/Avoiding Death on the Yellow Brick Road.md` ## People / Organizations - Author: Joe Schmidt IV - Referenced organizations / examples: OpenAI, Anthropic, 11x, FurtherAI, a16z - Retrieval names: Joe Schmidt, Yellow Brick Road, Rest of Oz, AI app layer, application layer, vertical AI, agentic workflows ## Neutral Summary Joe Schmidt argues that the AI application layer is not dead, but founders need to avoid building directly on the "Yellow Brick Road" where the major labs are already investing heavily. The Yellow Brick Road means horizontal, low-step-count, model-capability-driven work: code generation, writing, image generation, generic agents over standard connectors, and other areas where raw model progress and lab distribution are decisive. The "Rest of Oz" means more complex vertical or functional work where value comes from software, workflow, domain context, operational integration, governance, cost optimization, model routing, and customer-specific outcomes. Defensibility comes from: - data and learning flywheels from production workflows; - customer-specific UX surfaces that capture hidden workflow knowledge; - managing model variability across vendors and upgrades; - cost optimization across model tiers; - governance and compliance control planes; - focus on one vertical or function; - owning a system of work, not just a tool on top of someone else's system. The practical tests include: - tools-and-steps test; - system versus tool test; - P&L / outcome test. ## Why This Caught Attention This is directly related to the What To Build side of the project. It asks where builders can still create durable value when labs own powerful horizontal models and coding agents. ## How Theme Theory Relates Theme Theory can complement this source by asking which customer-side higher-order states are worth organizing a system of work around. Joe's frame says: ```text Build where workflow, domain complexity, governance, and production learning matter. ``` Theme Theory can add: ```text Build where those workflows support a meaningful desired state for a specific audience or customer set. ``` The connection to [Object Of Interest](../../core/object-of-interest.md) is strong. The "Rest of Oz" companies win because they are not just wrapping models; they understand the customer's lived workflow, constraints, exceptions, and desired outcome. That looks like the systems/business version of supporting a meaningful higher-order state. This also helps Theme Theory avoid becoming merely media-centric. The same logic that organizes audience-building creative may also help identify software/data/AI systems worth building: find the object of interest, then build the support surface around it. ## Deep Corpus Comparison This is one of the best WTB/software notes in the milieu lane because it gives a concrete boundary between shallow AI wrappers and durable systems. The `Yellow Brick Road` / `Rest of Oz` distinction maps well to TT: ```text horizontal model capability is not enough; durable value appears where real workflows, constraints, outcomes, and feedback loops matter. ``` Theme Theory can translate `system of work` into object language: ```text a system of work is a support surface around a consequential desired state. ``` That makes this source useful beyond startups. It suggests how to evaluate any software/data/AI extension: - does it support a real higher-order state? - does it understand the user's context and exceptions? - does it reduce uncertainty or path length toward an outcome? - does it learn from actual work? - does it become part of the arena in which the user acts? The source also creates a guardrail for WTB: do not build where the model labs will absorb the task unless the project owns workflow, context, audience, or outcome. ## Core Links - [What This Is](../../core/what-this-is.md) - [Creators, Builders, And Audience](../../core/creators-builders-and-audience.md) - [Object Of Interest](../../core/object-of-interest.md) ## Candidate Concepts / Edges - Rest of Oz -> build surface around complex higher-order states - system of work -> software support for an object of interest - vertical workflow -> domain-specific path toward desired outcome - governance/control plane -> support boundary for real-world stakes - model capability is not enough -> object/workflow/context matter ## Promotion Judgment - Promote to core? `maybe` - Reason: strong candidate for future What To Build / software-data-AI docs. It should be revisited during a deep corpus pass on building support. ## Open Questions - Is a "system of work" one business/software expression of support around an object of interest? - How does Theme Theory evaluate whether a vertical workflow is meaningful enough to organize audience and product around? - Should `Rest of Oz` become an external reference example for the software extension of Theme Theory?