Skip to content

AI Platform V1 Decision

Current Decision

The AI platform will proceed under the Tentacles segment with a prototype-first scope.

The first real pilot use case is now fixed:

  • TV Mount Australia is the first pilot tenant and business workflow
  • booking-related flow is part of the pilot direction
  • Google Calendar integration is expected for booking handling

Channel Decision

  • WhatsApp is mandatory for v1
  • email is included in v1
  • web and voice remain later stages

The mandatory interaction rule for v1 is now:

  • inbound and outbound WhatsApp for the primary customer flow
  • email as a supported channel in the same prototype
  • no attempt to ship voice or web chat before the human review path works

Scope Tightening

The earlier planning direction is useful, but the full stack is too heavy as an immediate first build if the main objective is a working prototype soon.

Prove one useful customer-service and booking-adjacent workflow for TV Mount Australia that works over WhatsApp and also supports email.

V1 should prove:

  • 2 to 3 internal pilot tenants on a shared core platform
  • TV Mount Australia as the first live workflow
  • one primary virtual employee with bounded scope
  • one knowledge base per active tenant as needed
  • one inbound WhatsApp path
  • one inbound email path
  • one operator review path
  • one booking integration path for the first pilot

Keep the stack modular, but do not deploy every possible supporting system before the first useful interaction exists.

Priority order:

  1. review queue and operator workflow
  2. application / workflow path
  3. tenant state and persistence
  4. knowledge retrieval
  5. observability hardening

Current infrastructure preference from the project owner:

  • full machine separation now
  • prefer LXC over VM where practical
  • keep the split as shared core infrastructure, not duplicated per tenant

Planning Risks

  1. Overbuilding the stack before validating a client workflow.
  2. Treating multi-tenant design as if it requires full enterprise isolation on day one.
  3. Letting channel count outrun operator control.
  4. Building against fragile production infrastructure too early.
  5. Locking commercial design before the operator workflow is proven.
  6. Spreading effort across all three pilot tenants before TV Mount Australia works cleanly.
  7. Letting observability and platform extras delay the review queue.

Revised Four-Stage Roadmap

Stage 1

  • lock TV Mount Australia as the first live pilot
  • design the review queue and holding-response flow
  • keep WhatsApp mandatory and email included
  • define the first booking workflow boundary
  • define the first operator workflow and escalation path

Stage 2

  • build the shared business-scoped pilot stack on separated LXCs
  • deploy the minimum service set needed for the TV Mount Australia pilot
  • prove inbound/outbound message flow, holding response, and human notification
  • keep the review queue simple and explicit

Stage 3

  • add Google Calendar booking actions if the review loop is already stable
  • add stronger observability
  • add repeatable tenant setup
  • activate the second and third internal pilot tenants on the shared core

Stage 4

  • harden isolation
  • improve deployment automation
  • expand channels and agent roles

Current Machine-Separation Direction

Current first-pass machine split proposed for the shared core stack:

  • cbr-sh-dify01
  • cbr-sh-n8n01
  • cbr-sh-postgres01
  • cbr-sh-qdrant01
  • cbr-sh-langfuse01

Operational interpretation:

  • keep the platform core separated by service
  • do not create one full stack per tenant
  • onboard TV Mount Australia first
  • bring Tentacles and Souza Hub or telephony onto the same shared core only after the first workflow is stable

Practical Note

That full split is valid as the intended architecture, but the critical path is not the number of containers. The critical path is the human-in-the-loop review flow.

Gemini peer review agreed on the main correction:

  • prioritize the review queue, holding response, and human notification cycle first
  • treat Dify and Langfuse as deferrable if they slow the first working deployment
  • keep the first useful deployment as small as possible even if the LXC split exists from day one