BezelIQ Platform Roadmap
internal prototype · canonical JSON + Dreamborn Forge HTML
internal generated
design_doc · markdown

BezelIQ Platform Roadmap

BezelIQ Platform Roadmap Date: 2026 04 23 Status: Active Supersedes: docs/roadmap.md The Play Build a platform to demonstrate, show its power, and generate quick cash. Two revenue tracks run in parallel: Product sale — we build your AI operations team, lump sum. CCOS2 is the proof. Tech license — here's the platform, deploy it yourself, revenue share. The de...

Agent Handoff
Start Here

BezelIQ Platform Roadmap Date: 2026 04 23 Status: Active Supersedes: docs/roadmap.md The Play Build a platform to demonstrate, show its power, and generate quick cash. Two revenue tracks run in parallel: Product sale — we build your AI operations team, lump sum. CCOS2 is the proof. Tech license — here's the platform, deploy it yourself, revenue share. The de...

Completion Evidence

No explicit evidence field yet. Require tests, screenshots, linked PRs, or reviewed outputs before marking complete.

BezelIQ Platform Roadmap

Date: 2026-04-23 Status: Active Supersedes: docs/roadmap.md

---

The Play

Build a platform to demonstrate, show its power, and generate quick cash. Two revenue tracks run in parallel:

  • Product sale — we build your AI operations team, lump sum. CCOS2 is the proof.
  • Tech license — here's the platform, deploy it yourself, revenue share.

The demo sequence proves both: small → medium → big.

1. Assistant — personal AI, daily brief, task management, scheduled routines 2. Marketing — content calendar, BDR outreach, watch it run in real time 3. Dev project — big project decomposes into phases → tasks → execution, watch a phase complete end-to-end

---

Priority 1 — Dev Projects

The platform must handle big projects today. A project decomposes into phases. Phases decompose into tasks. Tasks have dependencies. Claire orchestrates at every level.

What gets built:

  • workflow_instances gains parent_id uuid references workflow_instances(id)
  • Three templates: project, phase, dev_task
  • workflow_steps gains depends_on uuid[] — task dependencies
  • BA (Priya) does the intellectual decomposition — receives the project brief, produces the phase breakdown with specs, receives each phase and produces the task list. The thinking work.
  • Claire orchestrates state — spawns instances, routes work to the right role, advances the workflow when steps complete, holds at exec gates. The plumbing work.

Workflow hierarchy: `` Project instance → Claire posts to roles.ba → BA (Priya) produces: phase list, each phase named + scoped + specced → Exec gate: Justin reviews phase breakdown before anything spawns → Claire spawns N Phase instances, posts each to roles.ba → BA (Priya) produces: task list for the phase, each task specced with dependencies → Exec gate (optional): Justin reviews task breakdown → Claire spawns M Task instances respecting dependency order → dev_task: spec → code → review (existing) → All tasks in phase complete → phase done → Claire reports up → All phases complete → project done ``

  • Receives BA output at each level, materializes child instances
  • Dependency gate: task not posted to queue until all depends_on tasks are complete
  • Holds at exec gates — workflow does not advance until approval recorded in Exec Inbox
  • Project phase breakdown complete → exec review before phases spawn
  • Phase task breakdown complete → exec review before tasks spawn (optional per template)
  • Gates surface in Exec Inbox (Priority 2)
  • Any agent can post a message to any other agent via agents.* topics — informational only
  • Any agent can post to roles.exec to reach Justin directly — this is messaging, not task routing
  • Hard guardrail: only Claire posts to peer role topics (roles.ba, roles.developer, etc.) to route tasks
  • Each agent reads its own agents.* inbox at session start — messages injected as context alongside memory
  • agents.justin = lightweight channel for things worth knowing but not decisions needed
  • Messages that require a decision surface in Exec Inbox instead
Priority 2 — Cockpit (Project Monitor)

The Cockpit is the operational view for running projects. Not the full Boardroom yet — just the project and agent monitoring surface needed to run real work.

Four sections:

  • Per-project Gantt view: phases as bars, tasks within phases
  • Status color: pending / in-progress / blocked / complete
  • Target dates on phases (set at project spawn, tracked against actual)
  • Dependency visualization — blocked tasks show what they're waiting on
  • Per-project, per-phase, per-task: token usage × model rate = dollar cost
  • Running total as work progresses
  • Cost pulled from task.complete payloads (model, token_count, duration_seconds)
  • Per-project breakdown view: how the project was decomposed by BA
  • Phase list with status, owner, target date
  • Each phase links to its artifacts: spec doc, design doc, roadmap, HCS definition snapshot
  • Task list within each phase — dependencies visualized, what's blocking what
  • The full paper trail from brief → phases → tasks, all in one place
  • Everything needing Justin's attention: gates, blocked workflows, flagged items, escalations from agents
  • Priority-sorted. Oldest blocking item at top.
  • Each item: context, what's blocked, what decision is needed
  • All running agents: role, current task, last activity timestamp
  • Idle agents shown — confirms platform is live
  • Quick view of what each agent completed today

---

Full Platform Vision

Everything beyond the immediate priorities. Ordered by logical sequence.

Phase 3 — Scheduling Primitive

Time-triggered and event-triggered workflows. Needed before Assistant and Marketing demos.

  • scheduled_triggers table: id, name, workflow_type, schedule (cron), payload, client_id, active
  • pg_cron job fires due triggers → posts work items to queue
  • Event triggers: event_triggers table, conditions evaluated on Supabase DB events or webhook inbound
  • Calendar data model: every workflow instance gets scheduled_at, started_at, completed_at
Phase 4 — The Boardroom

Full company OS. Extends the Cockpit into a strategic operating surface.

  • Now — live operations feed. BDR sent LinkedIn at 8:30, 8:47, 9:02. Who she sent to. What assistant is doing.
  • Strategy — declared goals and priorities. Lives in BezelBrain. Atlas owns it. Updated by talking to Atlas.
  • Measuring Strategy — KPIs tracking against strategic goals. Gap detection automated.
  • Gaps — delta between strategy and reality. Surfaced automatically.
  • Planned — calendar view of scheduled workflows. Content calendar. Upcoming milestones.
  • Projects — the Cockpit project view, embedded.
  • Finance — revenue, expenses, runway, invoices. Stripe + Mercury.
  • Pipeline — deals in flight, stage, expected close. HubSpot.
  • Team — agent roster. Who's running, idle, what they accomplished today.
  • Exec Queue — promoted from Cockpit, cross-domain. All decisions needed.
  • Intelligence Digest — what the system learned this week. BezelBrain contributions, Sentinel signals, patterns.

On naming: The Boardroom, not Cockpit. This is where the company runs from.

Phase 5 — Business Function Agents

Agent definitions + workflow templates for each business function.

  • Assistant — daily brief, task management, calendar awareness, morning routine
  • Marketing / BDR — content creation, LinkedIn outreach, campaign workflows, content calendar
  • Sales — HubSpot pipeline management, deal follow-ups, meeting prep
  • Finance — Stripe/Mercury reporting, invoice management, weekly revenue summary
  • Sentinel — competitive monitoring, signals posted to BezelBrain
  • API Scout — discovers new APIs, populates API Library
Phase 6 — Intelligence Layer

Intent expression → workflow execution. Self-healing when APIs break.

Full spec: docs/specs/2026-04-23-semantic-intent-layer.md

  • Intent Resolver agent (roles.intent)
  • API Library (pgvector semantic search over available integrations)
  • Self-healing loop: task.blocked → escalate to resolver → re-resolve → continue
  • Every heal writes a learning to Agent Brain
Phase 7 — Platform / Multi-Tenant

RedKey as a licensable product.

  • Onboarding flow: new deployment in < 30 minutes via scripts
  • Usage billing: per-client token cost tracking → Stripe billing
  • Agent marketplace: browse and deploy community agent definitions
  • Customer portal: client-facing view of their own workflows

---

Demo Script (When Ready)

Small — Assistant: Open The Boardroom. Show Now section. Morning brief running. Daily tasks queued. "This is your AI chief of staff."

Medium — Marketing: Show calendar. BDR messages scheduled. Watch one fire at exactly 8:30 — LinkedIn outreach to a named prospect. Content post went live at 9am. "This is your AI marketing and sales team."

Big — Dev project: Submit a real project brief. Priya (BA) reads it, breaks it into 4 phases with specs. Exec Inbox fires — review the breakdown, approve. Claire spawns Phase 1. Priya specs the tasks, dependencies mapped. Agents claim and work. Open Structure view — see the full paper trail: brief → phases → tasks → specs linked. "This is your AI engineering team taking a project from brief to shipped."

---

What Stays Hidden

The underlying infrastructure is not referenced in any UI, demo, or external document. All external language uses: "durable execution," "distributed agents," "guaranteed delivery," "permanent audit trail." The specific technology is a strategic advantage revealed at the right moment — not before.

---