4.9 KiB
provider-ai-entrypoint — why the AI is the front door
Phase: P0 Org scope (per W §W4, forward-compat for P5+): personal → org-scoped in P5
One page. The north star for everything in @features/ai-copilot/.
The problem with v2
v2 split the provider's interface across four distinct surfaces:
- quinn.my dashboard — manual data entry, review, status browsing
- quinn.admin — public-site CMS (provider website, blog, ad copy)
- coworker-agent in iMessage — conversational management (calendar, clients, hotels, tour stops)
- Claude Code + quinn.my MCP directly — when the above two weren't enough
Each surface had its own mental model, its own context, its own trust posture. The provider carried the synthesis in their head: "I approved a tour stop in iMessage, now I need to open admin and update the bio to mention Berlin." Nothing shared state automatically; nothing proactively noticed the gap.
The coworker-agent was the proof-of-concept that conversation was the right unit of work. It drove 100+ tools across the full business surface. The dashboards complemented it but were never subordinated to it.
v4 flips the hierarchy.
Three principles
1. Every business action has an AI-driven path
No action the provider takes on the platform should require opening a dashboard as the first step. Every action — onboarding a client, recording a deposit, drafting an ad, creating a tour stop, scheduling a fanout — has a conversational path through the AI. Dashboards exist for inspection and emergency fallback, not as the canonical entry point.
Concretely: if a provider can't accomplish something by talking to the AI, that is a gap in the platform's action surface (@ai/@skills/platform-*/actions/*), not a reason to promote the dashboard.
2. The AI has full context, always
The AI doesn't receive context only when the provider asks a question. It holds a continuously-assembled picture of the provider's business state: calendar, inbox, active prospects, pending approvals, tour schedule, content roster, finance position, hotel preferences, recent journal entries. When the provider opens a conversation, the AI has already loaded their world.
This is the structural difference from v2's coworker-agent, which was invoked point-to-point against the MCP and held no ambient state between calls. In v4, context is pre-assembled via ContextProvider implementations (see @packages/cocottetech-context-providers/) running against platform.api:3060.
3. The AI is proactive — it surfaces things the provider hasn't asked for
The provider doesn't have to poll their own business. The AI surfaces:
- Overdue follow-ups (prospect last seen 4 days ago; triage suggested reply was never approved)
- Hotel-availability changes for an upcoming tour stop (price dropped, alternative property appeared)
- Prospect-ghosting signals (high-warmth prospect went cold; triage confidence dropped below threshold)
- Daily digest: overnight specialist activity, pending approvals, upcoming calendar events
- Autonomous-rule triggers (standing instructions fired; brief H1 policy applied; receipt for awareness)
Proactive surfaces are delivered via push notification → chat (see brief C), iMessage fallback via @mac-sync, and the daily digest card (see I §1). The AI does not wait to be asked.
Dashboard role after P0
Dashboards (ai.cocotte.maison web-fe, any per-feature portal) serve three purposes post-P0:
- Inspector: read-only review of state the AI already surfaced ("show me the Tryst profile as a client sees it").
- Bulk-operation ergonomics: calendar views, asset libraries, prospect tables — tasks where a bigger screen reduces friction for the same outcome the AI already owns.
- Emergency override: when the AI got something wrong and the provider wants to fix it directly, bypassing a specialist.
None of these are "entering data because the AI can't handle it." If the AI can't handle it, the gap belongs in the action surface.
Related
- brief A — primary conversational surface (iOS).
- brief C — proactive push + iMessage fallback.
- brief H — autonomous rules (the "proactive" layer for standing instructions).
- brief I §1 — daily digest; audit spine.
- brief L — specialist fleet; ai-copilot as front door.
- cross-surface-fanout.brief.md §1 — "why conversation, not screens."
- provider-ai-context.contract.md — what context the AI holds.
- provider-ai-actions.contract.md — full action surface.
- provider-ai-interaction-modes.md — how the provider reaches the AI.