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 into separate domains — one per business, plus finance and personal — and each gets its own task views, content loops, knowledge context, and agent assignments. In practice that spans very different operations: a spa, a property-management firm, a construction advisory, a consulting practice, internal finance research, and personal projects.
The specific businesses aren't the point. The structure is. Anyone running more than one venture — or any organization coordinating several operating units — hits the same wall: every unit needs its own context, but switching between them means losing the thread of whatever was in progress. The domain model lets you work inside one business or across all of them in a single view, without rebuilding context each time.
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 across every business stays visible without manual re-entry each week.
The comments section is also the primary surface for human-agent communication: the operator 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: the operator 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. The operator 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.
The other side of capture is a reader. The same records — agent plans, notes, and structured data — render in a clean, legible reader built into the platform, with Mermaid diagrams drawn inline so a workflow or process map reads at a glance instead of sitting as raw syntax. Because the reader runs over the database itself, you're reading the live record where it lives, not an exported copy of it.
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. The platform runs as a content engine, not just a notes pile. It generates seed content for four separate businesses — shaped for blogs, LinkedIn, and Instagram — drawing on each business's own knowledge layer so drafts sound like the business instead of a generic model. Two loops run side by side: a Hermes-driven loop that drafts and stages content for review directly inside Supabase, and a fully programmatic pipeline that still hands off to agents at specific steps, so routine stages run on rails while judgment calls stay agent-assisted. Telegram session transcripts are summarized daily and mined for content-worthy stories from real work, and approved drafts can be pushed to the right site by an execution agent. Rejecting a draft requires a written reason, which sharpens the next round.
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 every business 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.