Bezel Team project-yaml
People with real product ideas need more than a coding agent or clickthrough demo. They need a guided production process that turns intent into reviewed screens, architecture, build-ready artifacts, implemented software, deployment, and iteration. Bezel is Dreamborn's AI-first product studio infrastructure for that workflow.
- Should Bezel Core be permissive open source, source-available, or delayed until Team has first users?
- Is the first Team intake path GitHub Issues, Linear, or both?
- Should Team initially run workers in Justin-managed infrastructure only, or support customer-connected workers in V1?
- What is the first paid buyer profile: solo founder, small engineering team, or agency/product studio?
People with real product ideas need more than a coding agent or clickthrough demo. They need a guided production process that turns intent into reviewed screens, architecture, build-ready artifacts, implemented software, deployment, and iteration. Bezel is Dreamborn's AI-first product studio infrastructure for that workflow.
No explicit evidence field yet. Require tests, screenshots, linked PRs, or reviewed outputs before marking complete.
People with real product ideas need more than a coding agent or clickthrough demo. They need a guided production process that turns intent into reviewed screens, architecture, build-ready artifacts, implemented software, deployment, and iteration. Bezel is Dreamborn's AI-first product studio infrastructure for that workflow.
- Should Bezel Core be permissive open source, source-available, or delayed until Team has first users?
- Is the first Team intake path GitHub Issues, Linear, or both?
- Should Team initially run workers in Justin-managed infrastructure only, or support customer-connected workers in V1?
- What is the first paid buyer profile: solo founder, small engineering team, or agency/product studio?
Machine-readable source fields
bezel.project
| problem | segment | success |
|---|---|---|
| Has a real product or internal tool idea but cannot translate it into production-ready UX, architecture, and implementation without hiring a full product/dev team. | founder_or_operator_with_product_idea | Can walk through a guided process, review concrete wireframes/screens, approve a build plan, and receive working production software rather than a clickthrough demo. |
| Understands the workflow pain deeply but lacks software design and engineering infrastructure. | small_business_or_domain_expert | Sees their workflow converted into screens, data model, build phases, and a hosted product they can actually use. |
| Needs delivery leverage for client product builds. | agency_or_consultant_later | Uses Bezel as a repeatable production system for design-to-build delivery after the first-party workflow is proven. |
People with real product ideas need more than a coding agent or clickthrough demo. They need a guided production process that turns intent into reviewed screens, architecture, build-ready artifacts, implemented software, deployment, and iteration. Bezel is Dreamborn's AI-first product studio infrastructure for that workflow.
bezel-team
Bezel Team
intake
production_product
AI-first product development infrastructure for people who want real production software built
Bezel
External surfaces, docs, UI, repos, and customer language use Bezel only. RedKey is legacy/internal historical context and should not appear in product copy.
- RedKey
Bezel
1
project.yaml
The product lives under Dreamborn as build.dreamborn.ai. Customer-facing language can say Dreamborn Build powered by Bezel or Bezel by Dreamborn; avoid RedKey.
dreamborn.ai
build.dreamborn.ai
Bezel
Dreamborn Build
2026-05-04T12:49:12.473Z
Open-core distribution wedge plus hosted team SaaS
Do not over-invest in public Core unless it directly improves Team acquisition, trust, or onboarding.
| tier | buyer | price | value |
|---|---|---|---|
| Core | individual developers | free | local runner and proof-of-concept trust |
| Team | small engineering teams | paid per seat or per active repo | hosted dashboard, shared history, managed workers, review gates |
| Enterprise | regulated or larger teams | annual contract | SSO/RBAC, retention, audit receipts, private deployment, support |
- Product owner intake for real software, not demo/clickthrough builds
- Screen inventory, wireframe generation, and HITL approval flow
- UX flow and state breakdown including empty/loading/error/success states
- Architecture and production constraints artifact
- Build plan from approved screens and architecture
- Managed AI dev team execution against approved artifacts
- Production deployment option on Dreamborn infrastructure
- Review gates at Design, Architecture, Build Plan, PR/Implementation, and Deploy
- AI-first opportunity map included in design phase
- Generic coding-agent SaaS for engineering teams
- Public Core CLI
- Clickthrough-only prototypes as deliverables
- Autonomous build before screen/design approval
- Marketplace
- Enterprise self-hosting
- Public explanation of private ledger implementation details
- Included full build/operation of all recommended support agents; those are expansion scope unless explicitly purchased
Bezel Ledger
Do not expose provider mechanics, topic identifiers, operator credentials, or private governance repair flows in public repos or product UI.
tamper-evident audit receipts and durable execution history
private ledger provider behind the RunLedger/ReceiptStore interface
Production product-studio and delivery engine
- Guided product intake and problem framing
- AI-assisted screen inventory and user-flow mapping
- Human-reviewable wireframes and screen states before build
- Architecture and production-readiness planning
- Build-ready artifacts and acceptance criteria
- Managed AI dev team execution with review gates
- Production deployment on Dreamborn infrastructure or customer-connected hosting
- Persistent product history, decisions, proof bundles, and iteration backlog
- Managed product support and improvement cycles
- AI-first opportunity map that recommends supporting agents and workflow shifts from SaaS to agentic operations
- Optional paid agent-build expansion using Dreamborn/Bezel infrastructure
Future distribution wedge only after Bezel Product Studio workflow is repeatable
- Hosted multi-tenant control plane
- Private ledger implementation
- Enterprise audit receipts
- Managed worker fleet
- Billing/metering
- Team RBAC/SSO
- Governance repair intelligence
- Private agent memory and production reconciliation internals
- CLI: bezel init, bezel run, bezel watch
- Local workflow file: bezel.workflow.md or project.yaml-derived config
- GitHub Issues or Linear task adapter
- Per-task worktree manager
- One local agent runner provider to start
- Local SQLite/Postgres event log
- Basic run lifecycle: queued, running, blocked, review, done
- Local dashboard
- Proof bundle: changed files, test command output, summary, PR link when available
- Provider interfaces: QueueProvider, RunLedger, ReceiptStore, TaskStateAdapter
TBD after business review; likely permissive for CLI/SDK or source-available for server pieces if copy risk is too high
- Should Bezel Core be permissive open source, source-available, or delayed until Team has first users?
- Is the first Team intake path GitHub Issues, Linear, or both?
- Should Team initially run workers in Justin-managed infrastructure only, or support customer-connected workers in V1?
- What is the first paid buyer profile: solo founder, small engineering team, or agency/product studio?
Build the outcome-oriented product studio first for people who want products built. Extract developer/team infrastructure later once the workflow is proven.
Bezel Team/Core later, only after the product-studio workflow is repeatable
Public Core demonstrates the agent-runner workflow. Team owns the daily operational value and monetization.
Dreamborn Build / Bezel Product Studio
true
Dreamborn Build turns a product idea into production software through multi-model research, screen-by-screen design, AI dev execution, and managed hosting.
Rent an AI product team with a production process: design the product, review the screens, approve the plan, build the software, deploy it, and keep iterating.
- Not a demo harness
- Not a prompt collection
- Not a blockchain product in public positioning
- Not another chat UI for code generation
Not the primary wedge. Developers may later use Bezel infrastructure, but V1 serves product owners who want real software delivered.
The customer should always know where they are in the product-build process and what they are doing next.
Every review screen must have one primary next action and one clear escape: request changes, ask question, or save for later.
Orientation data should come from phase/gate status and artifact approval state, not static copy.
Persistent project progress rail plus current-step header plus next-action panel.
- Where am I?
- What phase is this?
- What did Bezel just produce or learn?
- What decision/action is needed from me?
- What happens next after I approve or request changes?
- What is blocked?
Receipt writes go through an interface; local/dev uses a database event log, Team uses private Bezel Ledger.
Bezel Team owns team state, run visibility, policy, review, billing, and durable history.
Workers execute in isolated repo workspaces with scoped secrets and explicit lifecycle reporting.
- TaskSource
- QueueProvider
- WorkspaceManager
- AgentRunner
- RunLedger
- ReceiptStore
- ReviewGate
- NotificationSink
- PolicyEngine
- Instead of building only a CRM dashboard, identify a follow-up agent, lead research agent, and stale-opportunity recovery agent.
- Instead of building only a support portal, identify a triage agent, knowledge-gap agent, escalation agent, and customer-summary agent.
- Instead of building only an ops dashboard, identify monitoring agents, exception-resolution agents, and approval workflows.
Every product design pass should identify where the customer can move from SaaS-shaped human workflows to AI-first workflows.
AI-first opportunity map: recommended agents, workflow automations, human review gates, and data/permission requirements discovered during product design.
Lightweight agent suggestions and workflow concepts are included in the design process. Building and operating the actual support agents is additional scope/pricing because it uses Dreamborn/Bezel infrastructure beyond the base product build.
Bezel does not only ask what app you want. It asks what work should stop being manual SaaS work and become agent-supported work.
- intake synthesis
- AI-first opportunity map
- screen map and wireframe critique
- architecture review
- build plan review
- implementation/proof review
- release readiness review
- iteration strategy
Every major product decision should support multi-model research and collaboration, not a single-model black box.
Raw model outputs are evidence. The product should save both the model-review evidence and a human-readable synthesis artifact before the next gate.
Bezel should ask models to disagree, compare alternatives, critique assumptions, and produce synthesized recommendations at key gates.
| role | purpose | model family |
|---|---|---|
| product_strategy_critic | Challenge positioning, scope, user value, and product clarity. | Claude |
| market_and_systems_researcher | Broaden research, compare patterns, suggest AI-first workflow shifts, and stress-test market assumptions. | Gemini |
| implementation_reviewer | Translate decisions into executable artifacts, testable implementation plans, and code review. | OpenAI/Codex |
Dreamborn researches your product with multiple AI perspectives, shows the tradeoffs, and turns the best answer into build-ready artifacts.
- Production product from day one; no fake task loops, canned demo states, or clickthrough-only deliverables.
- Every build starts from approved human-reviewable screens/wireframes, not only prose requirements.
- Every screen has states: default, empty, loading, error, permission/locked where relevant, and success/complete.
- Build cannot start until product intent, screen map, key wireframes, architecture, and plan are approved.
- No external product surface uses RedKey naming.
- Private ledger mechanics stay hidden behind Bezel Ledger abstractions.
- Human review and stop controls are first-class at every phase.
- Secrets are never passed through repo files, prompts, or public logs.
- Design artifacts must distinguish included product-build scope from optional supporting-agent expansion scope.
- Major gates should include model comparison evidence and a synthesized recommendation, not a single unchallenged model answer.
- Every customer-facing screen must show current phase, current decision, and next action.
- MODEL_COLLABORATION_PROTOCOL.json
- AI_FIRST_OPPORTUNITY_MAP.json
- INTENT.json for Bezel Product Studio
- SCREEN_MAP.json for HITL wireframe/screen breakdown
- WIREFRAME_SPEC.json defining screen state requirements and review gates
- REQUIREMENTS.json for production V1
- ARCHITECTURE.json separating product studio, design layer, execution layer, hosting, and private ledger
- POLICY.json with naming, production, secrets, and no-clickthrough-deliverable rules
- PLAN.json with M-00 substrate audit before implementation dispatch