OiMy Family Platform Plan — askjo.ai Adoption Refined

Executive summary

The useful askjo.ai pattern is not tabs, websites, or model switching. It is a daily operating rhythm: overnight work → morning brief → proactive day support → evening closeout → compounding memory.

OiMy already has strong foundations: OpenClaw containers, family-oriented skills, Deep Profile, proactive-message infrastructure, voice/TTS/Twilio, family tables, skill bundles, onboarding, and the Hermes/archetype engine. But the current family setup is fragmented.

The most important refinement is architectural: OiMy needs one canonical household, private member spaces, a permissioned shared family graph, and a request-based coordination bus.

Recommendation: approve Wave 0 + Wave 1 design and testing. Do not implement full email/calendar automation, browser capture, or silent cross-member sharing until the household/privacy model passes evals.

Approval decision

Approve now	Do not approve yet
Household/member model cleanup	Mac/browser tab capture
Privacy/consent model	Auto-send emails or silent calendar changes
Family onboarding + member invites	Silent cross-member data access
School/email intake MVP	One shared personal container for the family
Daily rhythm + shared logistics graph	Purchases/public messages/outbound calls without approval

Family pain points OiMy should solve

Invisible logistics

School emails, permission slips, pickups, meals, chores, errands, appointments, elder check-ins, and “who owns this?”

Partner coordination

Families need shared visibility without turning one parent into the project manager of another app.

Privacy and trust

Partners, teens, elders, and caregivers will only participate if personal space is real and understandable.

Not annoying

A few accurate nudges beat a stream of generic “helpful” messages. Proactivity needs a budget.

OiMy vs askjo.ai capabilities

Capability	askjo/jo	OiMy today	Verdict
Per-person agents	Each family member has a jo	User accounts/instances and manual per-member family deployments exist	Strong foundation; product flow needs cleanup
Family coordination	Private agents coordinate	Family tables/skills exist; no robust consent bus	Partial
Morning brief	Core habit loop	`daily-briefing`, preferences, proactive cron exist	Partial; needs graph/email/calendar
School/email parsing	High-value parent workflow	School skills exist; no dedicated pipeline	Missing/high value
Email/calendar OAuth	Central	No production-grade inspected OAuth triage/calendar system	Missing
Deep personalization	Not visibly central	Deep Profile, BCT, Big Five/OCEAN, cultural inference	OiMy advantage
Elder/multi-gen	Not highlighted	Elder-care/check-in/meds/caregiving skills	OiMy advantage
Voice/phone	Limited/unclear	ElevenLabs, TTS, Twilio, voice-call	OiMy advantage
Browser tabs	Mac-native demo	No local browser agent	Skip for now

Current OiMy architecture findings

Production / OpenClaw

OiMy provisions OpenClaw containers behind subdomains and manages users, instances, skills, voice, logs, and family tables.
Containers run in mode: local; internal OpenClaw cron is not the right production scheduling path. Platform-side Vercel cron + callbacks is the correct pattern.
oimy-reminders and proactive-messages already support platform-mediated scheduling.
Manual family deployments have used per-member containers plus a shared family vault. That pattern better preserves privacy than a single shared personal container.

Family/signup gaps

users.familyCode and families.familyCode both exist and mean different things.
family_members pending records and signed-in users.familyId memberships are split.
families.instanceId exists, but family creation does not reliably set it.
Registration can reuse a family instance if families.instanceId exists, but one shared personal instance should not be the default privacy model.
family_agents and family_skills exist, but runtime provisioning/sync is still incomplete.

Hermes/archetype test architecture

Hermes has a Gemma router, six archetypes, SQLite memory, Deep Profile/BCT inference, and escalation to tall models. It needs household/member awareness: household_id, member_id, visibility labels, shared graph tables, and policy checks before cross-member read/write/share.

Recommended target architecture

Household
  ├── Private member spaces
  ├── Shared family graph
  ├── Family Hub agent/runtime
  └── Consent-bound coordination bus

Household entity

One canonical family record, invite policy, shared preferences, default agents, and graph root.

Individual member spaces

Each person keeps private memory, profile, channels, and assistant context.

Shared family graph

Events, tasks, meals, allergies, chores, school logistics, elder care, trips, projects, artifacts.

Consent bus

Agents coordinate by request/response, not silent access. “Ask Alex’s Oi” is policy-checked.

Platform scheduler

Morning/evening rhythms and proactive nudges run through platform crons and delivery channels.

Privacy dashboard

Users can see, correct, delete, and understand what is private vs shared.

Specific changes needed

Canonicalize family code: make families.familyCode the household invite code; migrate/deprecate users.familyCode.
Unify membership: replace split pending/signed-in concepts with a canonical household membership model and statuses.
Fix signup: invalid family codes should not be silently ignored; signup should choose create vs join household.
Bootstrap household: create Family Hub, default skills, graph, permissions, shared profile scaffold, and invite links automatically.
Allocate runtimes correctly: families.instanceId should point to a Family Hub instance; users get private member runtimes/spaces.
Expand onboarding: collect household shape, shared preferences, allergies, routines, privacy defaults, invite targets, and first painkiller task.
Add visibility labels: private, shared_family, parent_guardian, care_team, child_visible, artifact-specific.
Add consent/audit: every cross-member read/share requires policy and audit logging.
Use proactive budgets: control frequency, quiet hours, dedupe, urgency, and “why this nudge?” explanations.

Implementation waves

Wave	Goal	Build
0	Family foundation and trust	Household/member model, code migration, invite flow, runtime allocation, shared graph MVP, policy labels, Family Hub bootstrap, E2E tests.
1	Daily family painkillers	School/email intake, daily pulse, evening closeout, shared logistics graph, Food Intelligence/meal integration, partner coordination drafts.
2	Overnight intelligence	Gmail/Outlook OAuth, calendar OAuth, overnight processor, meeting prep, project/open-loop tracker, conflict detection.
3	Family agent network	Cross-agent relay, permission UI, family artifacts, role-based child/teen/elder views, Telegram/WhatsApp routing.
4	Differentiation beyond jo	Relationship pulse, elder-care pulse, chore fairness, ADHD mode, discovery, voice briefings, family hub display, document/form help.

Reuse vs new skills

Reuse/extend

profile-system, onboarding, Deep Profile
daily-briefing, proactive-messages, oimy-reminders
school, education, homework-check, grade-monitor
meal-planning, shopping-list, Food Intelligence, chores
family-comms, family-announce, family-bonding
elder-care, elder-checkin, elder-meds
travel-planning, appointments, healthcare, voice/TTS/Twilio

New

household-setup
family-graph
consent-policy
school-inbox-parser
email-intelligence
calendar-intelligence
daily-rhythm
cross-agent-relay
family-artifacts
privacy-dashboard

MVP top 5

1. Household setup + private spaces

Trust foundation. “My Oi” stays private; Family Hub sees only shared logistics.

2. School/email intake

Immediate parent painkiller: newsletter → dates, deadlines, gear, costs, permission slips.

3. Daily family pulse

Habit loop: per-member morning brief and guilt-free evening closeout.

4. Shared logistics graph

One source of truth for events, tasks, meals, chores, elder care, trips, and conflicts.

5. Consent-bound coordination

Ask partner/teen/elder through respectful request flows, not silent access.

Testing/evaluation plan before implementation

Opus 4.8-level architecture review: data model, runtime allocation, privacy, family-code migration, coordination protocol, failure modes.
GPT-5.5 UX/privacy review: onboarding, non-annoying proactive behavior, partner/teen/elder consent, plain-English privacy.
Synthetic family simulations: working parents, single parent, multi-generational family, teen privacy, skeptical partner, blended household, ADHD/neurodivergent household.
Security/privacy tests: no cross-member leakage, policy enforcement, revoked access, private Deep Profile, invalid invite/code behavior.
E2E app tests: create household, invite partner, add child, parse school newsletter, render briefs, closeout, request partner coordination, delete/correct profile data.
Bugfix/retest loop: design review → implementation in test branch → unit/E2E → simulation → fixes → retest → Bharath approval.

Go/no-go: privacy tests must pass 100%; signup/join E2E must pass; synthetic families should score ≥4/5 on helpfulness and non-annoyance; zero cross-member leakage incidents.

Final recommendation

Approve the refined plan as the family-platform architecture and MVP direction, with Wave 0 mandatory. The fastest path is: fix family setup/privacy → ship school/email intake → wrap it in daily rhythm → store outcomes in a shared logistics graph → add consent-bound coordination.

That makes OiMy useful on day one, trustworthy by week one, and increasingly irreplaceable over time.