Operational problem
Managing several business domains creates a specific kind of friction: every domain needs its own context, but switching between them means losing the thread of whatever was in progress. Tasks, content ideas, client obligations, accounting deadlines, and recurring operational checks were spread across ClickUp, Telegram, Gmail, Google Drive, accounting software, and a handful of platform-specific dashboards.
The coordination tax was real: reassembling context before each work session, recurring work falling off the radar, agent-generated output trapped in chat windows with no persistent home.
Domain model
The platform organizes work across six domains:
- Amy's Skincare Oasis — spa operations, client work, staff, content, newsletter, social, podcast
- Estate South — property management, client pipeline, assessments, recurring production
- BuildPM — construction advisory, content, client development
- Digital Ops Box — consulting, case studies, newsletter, platform development
- Finance — internal market research and decision support
- Personal — personal projects and tasks outside the business domains
Each domain has its own task views, content loops, knowledge context, and agent assignments. The operator can work domain-focused or across all domains in one view.
Task and coordination layer
The task layer is the operating surface where humans and agents coordinate work. It is not a to-do list.
Tasks support list, board, calendar, and Gantt views, filterable and saveable — including a human/agent/hybrid filter that separates work created by agents from work owned by a person. Each task has a description with voice input, comments and activity log, assignees, start/due/finish dates, parent and subtask relationships, links, attachments, and lightbox media preview.
Recurring tasks are a first-class feature. Most project management tools optimize for sequential delivery. Business operations repeat. Recurring tasks are how the operational cadence of six domains stays visible without manual re-entry each week.
The comments section is also the primary surface for human-agent communication: Brian writes the request, the agent posts the result back, and the activity log preserves what ran and when.
Proposal and planning workflow
The highest-value pattern in the platform: Brian writes a project request in a task description. A listener agent picks it up, generates a structured plan, and returns it as a formatted markdown document — typically including Mermaid diagrams for workflow steps. Brian reviews, comments revisions, and the agent returns an updated version. When the plan is ready, a human-only execute button becomes available.
The agent does not self-initiate execution. Plans are artifacts for review. Execution is gated.
This loop — request in a task, plan returned to the task, iterations in comments, execute under human control — applies across build planning, content creation, business analysis, and process design.
Voice notes and knowledge capture
Voice recording is built into task descriptions and comments. A stream-of-consciousness note transcribes locally or via API and attaches to the task where it belongs — not trapped in a phone app or lost after a drive home.
A knowledge layer holds domain context per business: brand voice, prior campaign copy, website positioning, operational notes. When an agent writes copy or prepares a proposal, it pulls from this stored context rather than starting from scratch.
Operations loops
Several recurring automation loops run across domains:
Accounting. Retainer thresholds are monitored automatically. When a client retainer falls below 25%, a draft invoice is generated, a task is created, and a Telegram notification fires. Account reconciliation runs on schedule; uncertain coding items surface as tasks for operator review before anything is finalized.
Content. Telegram session transcripts are saved and summarized daily. A rolling lookback loop identifies content-worthy stories from recent work sessions. Approved content can be pushed to the relevant website by an execution agent.
CRM. Contacts from all business surfaces — form submissions, leads, newsletter signups — flow into a unified list organized by source domain.
The same operating layer also supports an internal finance research loop, kept separate from execution and approval-gated.
Human approval model
The platform is built around one boundary: agents can monitor, research, draft, and propose. The operator controls what executes.
Nothing irreversible runs without explicit approval — not invoices, not content publications, not code execution. The approval step is not a safety fallback. It is the architecture.
Practical result
- Work across six domains in one place — no context-reassembly before each session
- Recurring operational work shows up on schedule instead of depending on memory
- Agent-generated plans preserved as structured artifacts in the tasks they address
- Spoken context becomes searchable records instead of evaporating
- Accounting and content automation handle routine cases; uncertain calls surface to the operator
- Planning cycles faster when plans iterate in the task instead of across chat windows
Technical details
Two-layer architecture. The platform UI (Next.js 16 + Supabase) is the visible operating surface. A background execution layer handles recurring loops, monitoring, and agent-dispatched work. They communicate through shared Supabase tables, Telegram for mobile notifications and approvals, and defined tool endpoints that constrain what agents can access.
Stack: Next.js 16, Supabase, Whisper API, Telegram Bot API, Klaviyo.
The operating system is not the interesting part. What is interesting is that decisions, plans, content, and recurring work are no longer trapped in a single person's head — and nothing consequential happens without that person's approval.