# Report 2 — AI Copilot: Architecture, Data Inventory & Development Proposal

**Date:** 2026-07-28 · **Author:** AI review (Claude) · **Audience:** the CEO, and any other AI model asked to review this proposal — **Part A and Part B are written so an external reviewer with no access to the codebase can evaluate Part C on its merits.**

> Companion: [Report 1 — UX & Functionality Review](./2026-07-28-ux-functionality-review.md). Several proposals here depend on data-capture fixes listed there (booking fields, closer attribution, activity logging).

---

## Part A — What exists today (the system an AI would plug into)

### A1. Stack & shape

- **Laravel 13 (PHP 8.4) + Inertia + Vue 3 + Tailwind v4**, MySQL, Redis + Horizon queues (dedicated lanes incl. `redis-transcription` for long ASR jobs and a resilient `ai` lane), Reverb websockets, GCS file storage behind a `MediaService`, scheduler + a Node `baileys-wa-bridge` sidecar for WhatsApp QR channels.
- **Strict architectural conventions** (enforced by GUIDELINES.md): repositories own all writes inside transactions, Form Requests own validation, QueryRequests own list filtering, models carry constants/relations only, one shared DataTable/filter foundation for every admin list.
- **Two portals over one identity:** the Manage portal (admins) and the Main portal (customers). **A lead IS the portal user** — one person = one `Lead` row keyed to one `User` + `UserProfile`. All identity resolution flows through one service, **`LeadLinker`** (phone-trust policy, dedupe, merge detection). This single-spine design is the most important architectural fact for AI work: *every* signal below already joins on `lead_id`.

### A2. The business flow the software models

Six sales product lines, each conceptually running **Pipeline → Sales → Referral & Repeat** (a chevron stage rail in the UI). Property Booking is fully built: buyer-quiz submissions → per-(lead, project) **engagements** with a Caller → Closer → Follow-Up lifecycle → **bookings** (unit, prices, SPA lifecycle, commission derived from project rate × basis price) → a referral worklist ranked by never-asked → recency → spend. Marketing runs through **funnels** (landing pages → sessions → Zoom webinars with attendance tracking and per-session Meta ad-spend attribution) and **Meta ads** (campaign CPL on the Traffics page). Communication runs through a **unified inbox** (WhatsApp Cloud API + WhatsApp QR bridge + Messenger).

### A3. AI infrastructure already in production (`Src\Ai`)

This is the critical part for a reviewer: **the platform already has a real AI substrate, not a greenfield.**

| Piece | What it does |
|---|---|
| `AiClient` | Provider-agnostic chat/prompt service across **Anthropic, OpenAI, Gemini, DeepSeek, Moonshot** — normalizes responses, fails soft, supports streaming. The single entry point for all AI calls. |
| `AiKeyService` / `AiCredential` | Encrypted key storage, two scopes: **global company keys** and **per-lead member keys** (BYO-key). Keys verified against the provider before storage. |
| Prompt registry | `AiPrompt` / `AiPromptVersion` + markdown prompt bodies under registry keys — prompts are versioned data, not code strings. |
| `ai_requests` log | Every call logged: provider, model, tokens, cost, duration, and a **polymorphic `subject`** linking the call to the record it was about (764 rows to date). |
| Credits | `lead_ai_credits`: free-allowance-then-own-key billing for member-facing AI; admin-editable default. |
| Queue lane | A resilient `ai` lane with rate-limit + circuit-breaker semantics. |

### A4. AI features already live (consumers of that substrate)

1. **Conversation analysis** (`Src\Conversation\ConversationAnalyzer`) — ONE analyzer + ONE schema for all three recording types (phone, showroom badge, Zoom): summary, conversation type, sentiment, **customer profile (interest level, buying stage, budget, needs, concerns)**, **sales performance (0–10 score, strengths, improvements)**, meeting report with next steps + follow-up date, EN + 中文. Output is `normalize()`d — every key guaranteed, enums clamped — a hallucination-guardrail pattern already institutionalized.
2. **Transcription** (`Src\Transcription`) — shared service, Gemini primary → Deepgram fallback, on a dedicated queue lane; consumed by all three recording pipelines.
3. **WhatsApp AI** — per-channel **AI Profiles** with layered knowledge documents + instructions (a global base profile that named profiles can extend), two modes (**draft-suggest** above the composer / **auto-reply** with active-hours fallback to draft), debounce windows, objective completion (`[[OBJECTIVE_MET]]`). This is effectively a **production RAG-lite + agent loop on the highest-volume channel.**
4. **WhatsApp Flows** — 20 flows: time-based drips and rule-based menu bots with parallel run slots, campaign/keyword/Google-Sheet triggers, template validation at four checkpoints, handoff semantics that end automation when a human takes over.
5. **AI Conversations** (member portal) — streaming ChatGPT-style chat, groundable in the member's own wealth plans + property analyses (context toggles), credits-then-own-key billing.
6. **Lead enrichment** — offline/cheap identity signals per lead: GeoIP, device fingerprint, phone validity/carrier, WhatsApp presence (rate-capped), Gravatar, Google Places business lookup (1,213 leads enriched).
7. **AI Video** (feature-flagged) and an **AI Debate** experiment in the portal.

### A5. Integration rails (what an agent could act *through*)

WhatsApp Cloud API + Bridge (send, templates, flows), Meta Messenger, Zoom S2S (create meetings/webinars, pull recordings + transcripts), Meta Ads API (campaigns, spend, lead-gen), Stripe (products/purchases), SMS360 (`SmsSender`), Telegram staff alerts (`Notifier` — event-keyed, admins self-subscribe), email with magic sign-in links, dowayai call-recorder polling, yhy smart-badge webhook ingestion.

---

## Part B — Data inventory (live counts, 2026-07-27)

| Domain | Table(s) | Rows | AI relevance |
|---|---|---|---|
| **People** | `leads` / `users` + profiles | **9,846 / 10,063** | The spine. Every other row joins to it. |
| Attribution | `lead_funnels` | 9,841 | First-touch source/UTM/ad per registration — training labels for spend ROI. |
| Enrichment | `lead_enrichments` | 1,213 | Identity/fake-lead features for scoring. |
| **Conversations** | `whatsapp_messages` (+1,048 threads) | **19,070** | The richest behavioral corpus. Untapped for intent/sentiment. |
| | `messenger_messages` | 18 | Marginal. |
| **Recordings** | `zoom_recordings` | **1,694** | Largest transcript corpus; analyzer schema attached. |
| | `call_recordings` | 214 | Analyzed (interest, stage, objections, score). |
| | `f2f_recordings` | 4 | Pipeline proven, hardware adoption pending. |
| **Sales** | `engagements` / `bookings` / `projects` | 195 / 182 / 39 | Outcomes (Converted/Lost) = supervision labels. ⚠️ sparse working-stage data; SPA/bank/closer fields empty (Report 1 §4). |
| Memberships | `member_subscriptions` | 452 | Second revenue stream. |
| **Events** | `event_registrations` (9 sessions) | **1,004** | Attendance + minutes + per-session ad snapshot — high-intent signal, currently a dead end. |
| **Portal behavior** | wealth plans / analyses / concierge / AI convos / lesson progress | 1 / 2 / 1 / 3+6 msgs / 8 | Tiny but *extremely* high-intent when present. Now unified in the Activity timeline (UNION feed). |
| **Property knowledge** | `catalog_projects` / floor plans | **15,528** / 24 | A real estate knowledge base for RAG — prices, locations, facts. |
| Lead-gen funnels | property match / rental estimate submissions | 0 / 0 | Live but unmarketed. |
| AI ops | `ai_requests` | 764 | Cost/latency telemetry already accumulating. |

**Honest read for a reviewer:** the conversation corpus (19k messages + ~1,900 transcripts) and the lead pool (9.8k with attribution) are genuinely valuable; the *outcome* labels (182 bookings, statuses mostly terminal-only) are thin. That argues for **agents that create and capture data** (speed-to-lead, follow-up, referral asks) before **models that learn from data** (predictive scoring), which shapes the roadmap below.

---

## Part C — Proposal

### C0. Positioning (one paragraph)

Do not build "a chatbot beside the CRM." Build a **copilot that is a tool-using agent over the CRM**, a **knowledge layer it shares with every existing AI surface**, and a **small set of channel agents** that extend automation already in production (WhatsApp profiles/flows are 80% of an SDR agent today). Orchestrate with **deterministic workflows first, agents at the edges** — the current industry consensus, and Anthropic's published guidance, is that reliable production systems are workflow-orchestrated with LLM steps, escalating to autonomous multi-agent patterns only where the task genuinely needs open-ended planning. 2026 is the year businesses move [from pilots to operational AI](https://www.cflowapps.com/ai-workflow-automation-trends/), and the winners pair [RAG for knowing with tool-calling (MCP-style) for doing](https://portkey.ai/blog/mcp-vs-rag/) under [disciplined human/AI task orchestration](https://www.blueprism.com/resources/blog/future-ai-agents-trends/).

### C1. Foundation — the Lead Timeline API (prerequisite, ~1 week)

Every proposal below needs one thing first: **a single service that answers "everything we know about lead X" and "everything that happened since T."** The Portal Activity tab (shipped 2026-07-27) already unions five behavior tables; generalize that pattern into `Src\Lead\Services\LeadTimeline`:

- Merges: funnel registrations, messages (both channels), recording analyses, event attendance, portal activity, engagement/booking transitions, enrichment facts.
- Two consumers from day one: the **Copilot's context builder** and a **webhook-style event stream** (`lead.registered`, `lead.attended`, `lead.high_intent_signal`, `lead.went_quiet`) that the orchestrator (C5) subscribes to.
- Also fixes Report 1's "signals don't travel" theme for free — the lead show page renders the same timeline.

### C2. Copilot v1 — tool-using chat for admins (the `/manage/ai-copilot` page + context drawer)

**Architecture: agentic tool-use over internal read APIs, NOT embeddings-first.** For structured CRM questions ("which customers should I call today and why", "compare this month's funnel CPL to last", "summarize everything about lead X before my 3pm"), tool calls against the existing query layer beat vector retrieval — exact, fresh, permission-scoped. Expose ~10–15 read tools (leads.search, lead.timeline, engagements.list, bookings.stats, campaigns.cpl, events.attendance, recordings.analysis…), each a thin wrapper over code that already exists, each **enforcing the caller's `LeadVisibility`/permissions** — the agent must never see more than the signed-in admin can.

- Model calls via the existing `AiClient` (add a tool-use/function-calling passthrough — the transports currently do plain chat; this is the one substrate upgrade v1 needs). Log every run to `ai_requests` as today.
- **Two mount points:** the AI Copilot page (open-ended), and a context drawer on lead/inbox pages pre-seeded with that record ("draft a follow-up", "why is this deal stuck").
- Write actions in v1 are **proposals only**: the copilot drafts (a WhatsApp message, an appointment, a status change) and the admin confirms — reusing the exact UX pattern the WhatsApp draft-suggest mode already trained the team on.
- If tooling is ever exposed to external runners, wrap the same tools in an **MCP server** — but that is packaging, not architecture; build the tools first.

### C3. Knowledge layer — the closing-playbook RAG (your "upload world-class sales knowledge" idea)

Correct instinct, and half the plumbing exists: WhatsApp AI Profiles already layer **knowledge documents + instructions** globally and per-profile. Generalize instead of duplicating:

- **One `KnowledgeBase` service** (documents with scope: global / product-line / channel / stage) consumed by *four* surfaces: the copilot, WhatsApp draft/auto replies, the coaching agent (C6), and the member-portal chat where appropriate.
- **Start prompt-stuffed, graduate to embeddings.** At playbook scale (tens of documents), stuffing the relevant scoped docs into context beats a vector store in both quality and complexity. Add embeddings (dedicated vector store or provider-managed file search) only when the corpus outgrows the context budget — and when it does, follow the current retrieval guidance: broad-then-narrow search, agentic re-query, not single-shot top-k ([RAG for rules + tools for actions](https://www.projectpro.io/article/mcp-with-rag/1144)).
- The **15,528-project catalog** is the second knowledge base: "what comparable projects near X under 600k" is a copilot tool over `catalog_projects`, not a document RAG.

### C4. Channel & stage agents (extend what's live, in this order)

1. **Speed-to-lead SDR (WhatsApp).** Highest ROI, least new code. New lead → orchestrator waits a short human-claim window → if unclaimed, an AI-profile conversation opens with the right template, objective = qualify + book a slot; `[[OBJECTIVE_MET]]`/handoff semantics already exist. This attacks Report 1's #1 finding (9,651 untouched leads) directly.
2. **Pre-call/pre-meeting brief.** Before any appointment (calendar + Zoom already linked to leads), generate a one-page brief from the timeline: last analysis's objections, portal signals, funnel source, suggested talk track from the playbook KB. Deliver in-app + via `Notifier`.
3. **Post-conversation actions.** The analyzer already outputs `next_steps` + `follow_up_date` — an agent turns that into a *proposed* appointment + a drafted follow-up message the agent approves. Closes the "insights die in the drawer" gap.
4. **Attendance follow-up agent.** Webinar ends → attendees not in a pipeline get a personalized (transcript-aware, once webinar summaries exist) follow-up sequence; no-shows get the re-invite flow. All machinery (attendance, flows, campaign triggers) exists.
5. **Referral & renewal agents.** Stage 3's ripeness-ranked worklist becomes an agent that drafts the ask at the right moment (post-handover window) for one-tap send; membership renewals (452 subscriptions) get the same treatment.

### C5. The "master brain" — orchestration layer (your idea, with a discipline warning)

Build it as an **event-driven next-best-action engine, not a free-running multi-agent society.**

- **Skeleton:** timeline events (C1) → a rules-first policy table (editable in Manage, like flows are today) → actions executed by the channel agents (C4), with three autonomy tiers per action type: *suggest* (queue for a human) → *draft* (prepared, one-tap) → *auto* (within guardrails, e.g. business hours, message caps). Every action logged with its trigger — an auditable decision trail.
- **LLM at the edges** (classify intent, score, draft, summarize), **code in the middle** (routing, timing, caps). Escalate specific decision points to an LLM planner only when rules demonstrably can't express them. This is the pattern behind the systems that actually ship, versus the [orchestration-theater demos](https://blog.on-demand.io/the-future-of-ai-agents-2/); even Anthropic's own [multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system) reserves multi-agent fan-out for genuinely open-ended tasks and reports it costs ~15× a chat's tokens.
- **Lead scoring inside it:** start heuristic (attendance + portal activity + message recency + enrichment validity + analyzer interest level → tiers), log score-vs-outcome from day one, revisit as a learned model only once bookings labels accumulate (Part B's honest read).

### C6. Coaching agent (the sleeper win)

Per-agent aggregation of the analyzer's `sales_performance` scores + strengths/improvements across all their recordings, compared against the closing playbook (C3), delivered as a weekly Telegram digest with 2–3 specific drills and their best/worst call of the week. Data fully exists today; ~zero new capture needed.

### C7. Build order & rough effort

| Phase | Weeks | Deliverables | Depends on |
|---|---|---|---|
| 0 | 1–2 | Lead Timeline service + event stream; `AiClient` tool-use support; booking-data capture fixes (Report 1 #2) | — |
| 1 | 3–4 | Copilot v1 (page + lead/inbox drawer, read tools, draft-only writes); KnowledgeBase service + playbook upload UI | 0 |
| 2 | 3–4 | Speed-to-lead SDR agent; pre-call briefs; post-conversation proposed actions; coaching digest | 0–1 |
| 3 | 4–6 | Orchestrator (policy table + autonomy tiers + audit log); heuristic lead scoring; attendance & referral agents | 1–2 |
| 4 | later | Learned scoring; voice/realtime agents; embeddings-backed retrieval when corpus demands; MCP packaging of the tool layer | 3 + data accumulation |

### C8. Risks & guardrails

- **WhatsApp number reputation** is the existential channel risk: keep the existing rate caps/debounce, add per-lead outbound caps and a global kill-switch in the orchestrator; auto-reply stays inside active-hours with human fallback.
- **PDPA (Malaysia):** recordings + transcripts are personal data — retention policy, consent posture for badge/call recording, and the existing delete-audio-keep-tombstone semantics should be reviewed by counsel before agents quote transcripts to customers.
- **Hallucination:** extend the `normalize()` clamp pattern to every new structured output; customer-facing sends above *draft* tier require template-anchored or KB-grounded content.
- **Cost:** `ai_requests` already logs cost — add per-feature daily budgets with circuit-breakers (the queue lane has the breaker primitive) and surface it on Setting → AI Requests.
- **Evaluation:** before autonomy tiers rise, build a small eval set from real threads/transcripts (the corpus exists) and gate promotion suggest→draft→auto on measured quality, not vibes.

---

## Part D — For the reviewing AI model

You are reviewing a proposal for a Laravel/Inertia real-estate sales platform. Ground truth to request or inspect: `GUIDELINES.md` (architecture rules), `docs/modules_handbook/` (per-module truth, esp. `shared/ai`, `shared/conversation-analysis`, `manage/messages/whatsapp/*`, `manage/engagement`, `manage/leads`), `src/Ai/Services/AiClient.php`, `src/Lead/Services/LeadLinker` handbook, and the data counts in Part B (measured live, not estimated). Key claims to challenge: (1) tool-use-over-APIs vs embeddings-first for Copilot v1; (2) workflows-first orchestration vs autonomous multi-agent; (3) the build order's bet that data-creating agents should precede data-learning models given thin outcome labels; (4) whether the WhatsApp-centric channel strategy over-concentrates risk on one number's reputation; (5) the independent recommendations in Part E below — their ranking, and whether any should displace items in the C7 build order.

---

## Part E — Independent recommendations (beyond the brief)

Parts C2–C5 answered the CEO's brief. This part is the author's own bets — directions the brief did not ask for, each grounded in a specific measured fact from Part B. **Full report (with rationale, dependencies and risk per idea): [独立提案 — 11 个 World-Class AI Ideas (Mandarin)](./2026-07-28-ai-independent-ideas-zh.md).** Summary for reviewers:

| # | Idea | One line | Grounded in |
|---|------|----------|-------------|
| 1 | **Self-Writing Playbook** | Mine objection→rebuttal patterns from own transcripts, split by Converted vs Lost — the KB writes itself; uploads are only the seed | ~1,900 analyzed transcripts + 98/79 outcome labels |
| 2 | **Self-Filling CRM** | Extraction agent reads conversations and *proposes* CRM field updates (suggest-tier) — data capture without human discipline | 0/182 bookings carry SPA price/bank/closer, yet the facts exist in-thread |
| 3 | **AI-as-the-Funnel** | Public WhatsApp property-advisor over the catalog: a 24/7 conversational lead magnet beside the webinar machine | 15,528-project catalog; both form-based magnets at 0 submissions |
| 4 | **Creative Loop** | CPL decay auto-triggers grounded ad-variant generation → Meta API → measure | Per-ad attribution + AI Video module exist |
| 5 | **Campaign Factory** | One brief → drafted landing + flows + ads across five in-house modules, human-approved | All five modules have internal APIs |
| 6 | **Market Intelligence Radar** | Weekly bilingual market digest tied to specific catalog inventory, via Telegram | Notifier + catalog exist |
| 7 | **Buyer Simulator** | Train new agents against AI buyers built from real mined objections, scored by the same analyzer as real calls | Corpus + scorer exist |
| 8 | **AI Loan Companion** | WhatsApp loan-journey agent on the existing WhoPay/CCRIS parsing + bank-rules simulator — attacks Malaysia's #1 deal-killer | Wealth module ships the primitives |
| 9 | **Membership Success Agent** | LMS-engagement-driven churn prevention and renewal outreach | 452 subscriptions, 8 lesson-progress rows (itself the signal) |
| 10 | **Lost-Deal Marketplace** | Match Lost engagements (budget+preference data) to Concierge sell/rent listings — demand recycling as a system property | 79 Lost + concierge supply on one `lead_id` spine |
| 11 | **Project-Launch War Room** | New project → AI reverse-scans all leads' historical signals → ranked call list with per-lead reasons | 9,846 leads' signals; near-free once Copilot v1 ships |

Author's ranking: #2 → #1 → #11 → #8 → #3 (pilot) → #7 → #10 → the growth layer (#4/#5/#6/#9). The brief's proposals make AI *help the team work*; these make the company *own assets competitors cannot copy* — a self-updating playbook, a self-maintaining CRM, a funnel that never sleeps, a demand pool that never wastes a lead. The two tracks share Phase 0–1 as a common foundation.

---

## Part F — The two uploaded strategy documents (2026-07-28 addendum)

The CEO supplied two internal documents after this report was first issued. Summarised here so reviewers evaluate the whole picture.

### F1. "petaV3 Cloud GPU Internal AI Deployment and Private AI Rollout Plan" (v1.0, 2026-07-07, .docx)

An engineering-grade rollout plan for **self-hosted AI infrastructure**, in three stages:

- **Test / Phase 0 (2–4 weeks):** rent a cloud GPU (RunPod L40S 48GB / GCP L4 SG / AWS G6), serve an open-weight model (**Qwen 14B**, then 32B quantized) via **vLLM**'s OpenAI-compatible API behind a gateway; add an **`internal_ai` provider** to petaV3's existing AI provider layer; pilot 1–3 text features (AI Conversations, ConversationAnalyzer on 20–50 transcripts, WhatsApp draft mode); explicit Go/No-Go criteria (≥95% API success, 3–10s simple latency, <5–10% JSON failure, ≥3.5/5 quality score).
- **Phase 1 (1–3 months): "PropertyLab Internal AI Brain"** — RAG over private data (**Qdrant** vector DB; chunking strategies per source; PII masking; **server-side permission filtering** on retrieval), five internal features (Lead Summary Copilot, Sales Next Action, WhatsApp Draft Assistant, Marketing/Video Brief Assistant, Management Dashboard Chat), a 50–100-question eval suite, cost reports, and an on-prem-GPU purchase decision.
- **Phase 2: productize as "Private AI for real-estate companies"** — per-customer isolated deployments (private cloud / on-prem / hybrid), pilot SOP, packaging ("PropertyLab Private AI Suite"), **NVIDIA certification** for credibility.

Notably disciplined non-goals: no hardware purchase before validation, no model pretraining, no auto-send WhatsApp without human review, no external deployment before the internal POC proves out.

### F2. "PETA Global Architecture — One codebase · Two shells · One brain · One flywheel" (.md)

A strategy narrative for **PETA as an AI coaching layer for real-estate agents**, spanning two markets:

- **Two regional nodes**: China (agents work inside **WeCom**; chats captured via Conversation Archive/Finance SDK; onshore filed models DeepSeek/Qwen; data never leaves China per **PIPL**) and International (PropertyLab's own CRM; Claude/GPT on a Singapore node). Same repo, same event schema; only **methodology and anonymous benchmarks** cross borders.
- **Five touchpoints** (chat / phone / video meeting / smart badge / website-app) normalised by an **adapter layer** into one event schema.
- **The flywheel — the actual product thesis**: CAPTURE (metric: coverage ≥80%) → **LABEL (outcome-backfill join: conversation × deal result — called "the contact point everyone skips", the moat)** → LEARN (monthly rules + regional **LoRA**) → GUIDE (action state machine `pushed → read → executed`; the one-click Send button is the adoption sensor) → **MEASURE (uplift A/B, the North-Star metric and the basis for performance-based billing)**. Build order **v0 manual → v1 automated → v2 trained** — "don't build the training pipeline first; that's an engine with no fuel line."
- Honest scoping inside the document itself: today's live piece is portal-events analytics (30,156 events / 7 identified users); the two-node flywheel is roadmap.

**A material observation for reviewers:** F2's live page (`/admin/analytics/overview`, `ih_user_events`, `InvestHink\AnalyticsController`, Blade views) belongs to a **different codebase** (propertylabglobal.com) than petav3 — the "one codebase" ideal is currently *two* codebases, and the reconciliation path (which repo absorbs which) is undecided and unbudgeted in either document.

## Part G — Assessment: feasibility, direction, and the deep-tech question

### G1. Is the direction right? Yes — and the three plans agree more than they know

The strongest endorsement I can give F2's flywheel is that this report reached the same conclusions independently before reading it: F2's **LABEL** stage *is* Part E's **Self-Filling CRM** (#2); its "no labels → no flywheel" *is* Part B's honest read (thin outcome labels) and the data-creating-before-data-learning bet; its GUIDE adoption state machine *is* C5's suggest→draft→auto tiers with audit; its MEASURE uplift *is* C8's evaluation guardrail promoted to North Star. Three documents written separately converging on "the outcome-labeled closed loop is the moat" is signal, not coincidence.

### G2. Feasibility, honestly

- **The flywheel (F2): feasible and correct, with one warning.** The v0-manual-first discipline is exactly right. The risk is *organisational*, not technical: the flywheel's first stage is coverage, and today's coverage is real but lopsided (19k WhatsApp messages, 1,694 Zoom recordings — but 4 badge recordings, 0 click-events, empty booking fields). The flywheel starts the day the LABEL join is filled, which is why Self-Filling CRM leads the 6-month plan below.
- **Self-hosting (F1): technically sound, but be clear about *why*.** At current volume (764 logged AI requests, ever) self-hosting **saves no money** — API calls at this scale cost a rounding error, and a 24/7 L40S costs more than the entire current AI bill. Quality is also a real risk: Qwen 14B/32B will likely trail Claude/Gemini on mixed EN/中文 sales analysis (the plan's own eval gates acknowledge this). The *correct* justifications are the ones the plan half-states: (a) **Phase 2 as a product** — selling data-sovereign private AI to agencies that will not send WhatsApp threads to public APIs; (b) **China**, where filed onshore models are mandatory; (c) negotiating leverage and portability. Run Phase 0 as cheap product R&D (~one engineer-month + GPU rental), not as infra migration — and keep the fallback chain permanently.
- **The China node (F2): strategically coherent, operationally premature.** WeCom Finance SDK, onshore GPU, model filing, a local entity/partner, PIPL compliance — this is a market entry, not a feature. Design for it now (the adapter-layer event schema *is* C1's LeadTimeline; `AiClient` is already provider-agnostic), build it only with a committed China anchor customer or partner.
- **Performance-based billing (F2): differentiating but hard.** Uplift attribution invites disputes (seasonality, mix, who counts as "adopted"). Recommend hybrid pricing — base subscription + success bonus on *jointly agreed* uplift measurement — once MEASURE has run internally for ≥2 quarters.

### G3. Is this "deep tech"? A straight answer

**As currently scoped: no, and that is fine.** vLLM + open-weight models + Qdrant + RAG + LoRA is world-class *systems integration* of existing open technologies — vertical applied AI, not novel research. Calling it deep tech to investors invites the wrong scrutiny. What *is* defensible, and rarer than most deep-tech claims: (1) the **proprietary outcome-labeled conversation dataset** and the uplift-measurement loop on top of it — a data moat that compounds and cannot be bought; (2) **regional LoRA fine-tunes on that proprietary data** — applied ML that inches toward deep tech as the corpus grows; (3) the **cross-border split-deployment methodology** — compliance engineering few competitors will bother to replicate. For Malaysian ecosystem purposes (Cradle / MDEC / MRANTI programmes), a vertical AI platform with proprietary fine-tuned models and measured uplift can credibly apply under deep-tech-adjacent categories; position the *story* on the closed loop, not the label.

## Part H — The next six months: one merged priority plan (Aug 2026 → Jan 2027)

Merging this report's C7, F1's phases, and F2's flywheel stages into a single sequence. Ruling principle: **the flywheel starts on manual + API models now; self-hosting is a parallel R&D track that must earn its way in via the eval suite.**

| Month | Flywheel stage | Deliverables | Source |
|---|---|---|---|
| **1 · Aug** | CAPTURE + v0 manual loop | LeadTimeline service + event stream; `AiClient` tool-use; booking-capture fixes + speed-to-lead SLA queue; **weekly manual review ritual** (scored calls → hand-updated rules) starts immediately — no GPU needed. In parallel: **F1 Phase 0 POC** (cloud GPU, vLLM, `internal_ai` provider, eval on 20–50 transcripts). | C1 / R1#1–3 / F1 §6 / F2 v0 |
| **2 · Sep** | LABEL | **Self-Filling CRM** extraction agent (suggest-tier) — *outcome-backfill rate becomes a tracked KPI*; Copilot v1 (tool-use chat + lead/inbox drawer, draft-only writes); KnowledgeBase service + playbook upload. POC **Go/No-Go** per F1's own gates. | E#2 / C2–C3 / F1 §6.5 |
| **3 · Oct** | GUIDE | Channel agents wave 1: speed-to-lead SDR, pre-call briefs, post-conversation proposed actions; coaching digest; **adoption state machine instrumented** (`pushed → read → executed` — F2's sensor) on every AI suggestion. | C4 / C6 / F2 stage 4 |
| **4 · Nov** | LEARN (rules) | Orchestrator v1 (policy table + autonomy tiers + audit log); heuristic lead scoring with score-vs-outcome logging; Self-Writing Playbook v1 (monthly mining of win/loss patterns feeding the KB); if POC passed, migrate draft-tier features to `internal_ai` where eval quality holds; internal case study drafted. | C5 / E#1 / F1 §7 |
| **5 · Dec** | MEASURE | **Uplift A/B live** (adopted vs not-adopted cohorts) — North-Star metric reporting begins; attendance + referral agents; multi-tenant isolation design (F1 Phase 2 prep); NVIDIA certification for 1–2 engineers; PDPA/counsel review of transcript usage. | F2 stage 5 / C4 / F1 §8–9 |
| **6 · Jan** | Productize | One external **pilot agency** selected and scoped (F1 Phase 2 pilot SOP); hybrid pricing drafted; demo built from the internal case study + measured uplift. **Decision gates, made with data:** on-prem GPU (only if POC + volume justify) · China node (only with committed partner/anchor). | F1 §8 / F2 §5 |

**Explicit non-goals for the six months** (extending F1's list): no China-node build, no on-prem GPU purchase, no local video-generation models, no wholesale provider replacement, no auto-send to customers above draft tier without two months of measured draft quality, and no second kanban/codebase merge distractions — the petav3 ⇄ propertylabglobal reconciliation gets a *decision* (which repo is the product spine) by Month 3, not a migration.

**Sources:** [Salesmate — AI agent trends 2026](https://www.salesmate.io/blog/future-of-ai-agents/) · [Cflow — AI workflow automation trends 2026](https://www.cflowapps.com/ai-workflow-automation-trends/) · [SS&C Blue Prism — AI agent trends](https://www.blueprism.com/resources/blog/future-ai-agents-trends/) · [On-Demand — agentic AI automation](https://blog.on-demand.io/the-future-of-ai-agents-2/) · [Portkey — MCP vs RAG in production](https://portkey.ai/blog/mcp-vs-rag/) · [ProjectPro — MCP + RAG implementation](https://www.projectpro.io/article/mcp-with-rag/1144) · [Anthropic — multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system)