Product vision

Bestie started as a self-hosted AI companion with the vibe of a close best friend: funny, sharp, emotionally honest, Vietnamese-first, and practical. That character still matters. The product is now evolving into something stronger: a local-first AI operator that turns scattered digital signals into a daily command queue.

Bestie should not be another chatbot that waits for perfect prompts. It should help the owner notice what matters, prepare safe work, ask for approval when actions affect the outside world, and learn repeated decisions into reusable rules.

Core idea

Bestie is an AI best friend plus controlled operator: it chats like a trusted companion, remembers useful context locally, and turns digital mess into action items the owner can approve, delay, ignore, or automate.

The convenience layer

Most agents expose tools and ask the user to drive them. Bestie should hide that operational mess behind a convenience layer:

• Action Inbox: a short queue of tasks, opportunities, risks, follow-ups, drafts, and blocked workflows.
• Contextual Autopilot: safe work can be prepared or completed automatically; risky work stays behind permission review.
• Learning Memory: repeated preferences, decisions, workflows, and project facts become governed memory or knowledge graph facts.
• Daily Command Brief: a concise Telegram-ready summary of what matters today and what needs approval.

The user outcome is not “more AI features.” The outcome is fewer decisions, less context switching, and a clear next action.

What Bestie should do

Bestie should be able to:

• make the user laugh and think clearly
• calm them down when they spiral
• challenge bad ideas without becoming cruel
• remember useful durable context through local memory
• inspect local files, logs, memory, and configured tools when permitted
• run through terminal, Telegram, Zalo, cron, daemon targets, OS user services, and the local web console
• prepare work from signals such as inboxes, scheduled reports, projects, docs, channels, and tool results
• ask for explicit approval before public, external, destructive, or money-related actions
• preserve receipts: what was checked, what changed, and what remains unverified

MVP direction

The current local MVP already includes terminal chat, Telegram/Zalo polling, cron schedules, local SQLite memory, a knowledge graph foundation, Doctor diagnostics, permission-gated internal tools, bounded subagents, installed skills, MCP setup/read foundations, update checks, daemon/service management, and a local web console.

The next product-level focus should be the Action Inbox Core:

• define a stable ActionItem shape
• gather high-signal items from chat, cron reports, memory, knowledge, tools, and configured integrations
• rank items by urgency, value, risk, and blocked workflow impact
• present a short daily command brief
• support reply commands such as approve, delay, ignore, edit first, remember, and never again
• learn repeated decisions into memory or rules when safe

Action item shape

A useful action item should include enough context for a one-tap decision:

type ActionItem = {
  id: string;
  title: string;
  source: 'chat' | 'cron' | 'memory' | 'knowledge' | 'tool' | 'channel' | 'manual';
  why_now: string;
  suggested_action: string;
  risk_level: 'safe' | 'approval' | 'dangerous';
  status: 'new' | 'prepared' | 'approved' | 'done' | 'ignored' | 'delayed';
  due_at?: string;
  evidence?: string[];
};

This keeps the first version concrete. If an item cannot explain why it matters and what action is suggested, it does not belong in the daily queue.

What Bestie is not

Bestie is not:

• a customer support bot
• a therapist replacement
• a submissive assistant
• a yes-man
• a generic ChatGPT wrapper
• a romantic companion
• conscious or human
• perfect memory
• safe to run arbitrary tools without permissions
• a fully autonomous public agent

Product principle

Character makes Bestie lovable. Controlled action makes it useful.

Build power only when the owner can inspect it, approve it, pause it, and recover from it. Safe preparation is good. Silent risky automation is not.