Personal Brand OS

A persistent agentic AI content team helping independent creators turn their ideas into resources that can help them build a personal brand on Instagram.

Comment

Inspiration and problem statement

Building something useful and explaining it well are different skills. A student may have a great project, or an independent creator may have useful knowledge, yet still struggle to decide what to share, who it serves, and how to turn scattered notes into a clear story.

Doing that alone means taking on the jobs of strategist, researcher, writer, editor, and reviewer. Ordinary AI chats can help with individual steps, but context and decisions can become scattered across conversations. A polished answer can also hide unsupported personal claims, weak sources, or a script that cannot fit its intended duration.

Personal Brand OS aims to make structured content support more accessible to people who do not have a professional content team. The goal is to help them communicate their own work and knowledge while keeping their judgment central to the process.

Solution overview: what it does

Personal Brand OS is a local application with a persistent team of seven AI specialists. The user talks primarily to Brand CEO, which coordinates specialists through a native task board. Each specialist has its own role, memory, and playbooks; they share a Markdown knowledge vault for research, strategy, scripts, and handoffs.

The user supplies an outcome, actual experiences, and source material. The team can refine the brief, study accessible public references, propose hooks, draft a timed script, and prepare editing and publication plans. Tasks carry dependencies so later work can use earlier handoffs. The dashboard makes the conversation, task state, and saved artifacts visible.

Outputs remain drafts. Major strategy decisions require human approval, and external publishing and messaging are disabled in the current prototype.

Key features

  • One conversation to coordinate a team. Brand CEO delegates work and brings specialist questions and results back into a persistent conversation.
  • Seven distinct specialists. Brand CEO, Brand Manager, Reference Builder, Hook Writer, Script Writer, Video Editor, and Publisher cover the workflow from discovery through draft delivery. The last two currently produce plans and draft packages.
  • Persistent context and handoffs. Separate profile memories and a shared Obsidian-compatible Markdown vault preserve work beyond an individual chat.
  • Visible task dependencies. A native SQLite Kanban board tracks assignments, blockers, attempts, feedback, and handoffs.
  • Reference analysis with evidence. Reference Builder can search public indexes, retrieve accessible individual clips, transcribe speech locally, extract timestamped frames, and request visual observations. Source availability and uncertainty stay explicit.
  • Script checks and revision. A native validator checks declared word counts and timed-shot pacing. It complements review; it does not establish factual accuracy or predict engagement.
  • A local control desk. The dashboard includes CEO conversations, direct streaming chats, team status, task details, session history, skills, and read-only vault previews.
  • Portable deployment. A pinned Docker runtime, provisioning scripts, and SQLite-aware backup/restore tools support moving the project between compatible Linux machines.

Technologies used and how it was built

The project uses Python, HTML, CSS, vanilla JavaScript, Docker Compose, and Bash around the official Hermes Agent runtime. Hermes provides persistent profiles, native agent tools, sessions, and SQLite Kanban dispatch. Markdown files form the shared knowledge vault, and server-sent events carry direct-chat updates.

The tested model provider is NVIDIA. Reference processing uses DDGS for public-index search, yt-dlp for accessible single-video retrieval, faster-whisper for local speech transcription, FFmpeg/FFprobe for media processing, and an NVIDIA Nemotron vision endpoint for sampled-frame observations.

The project adapts 26 Ootto content playbooks across 29 specialist assignments. Original playbooks and their MIT license are retained. The project-specific work includes role configuration, handoff conventions, provisioning and migration scripts, the dashboard and adapters, a script validator, and the bounded reference-acquisition integration. Hermes and Ootto are credited upstream components.

Challenges and accomplishments

One concrete challenge was that an AI review accepted a script with incorrect measurements: 116 spoken words were declared as 103, and the opening required 360 words per minute. The workflow was revised to use a deterministic validator alongside agent review. The resulting demonstration draft measured 97 words over 45 seconds, with every shot at or below 180 words per minute. It remains a hypothetical example requiring factual input and human review before publication.

Other engineering challenges included preserving private state during repeated provisioning, retaining committed SQLite WAL data during backup, constraining specialist tools, and keeping conversation history aligned with native task dependencies. The implementation includes explicit checks for these behaviors.

Current verification passed infrastructure/profile checks, 27 dashboard tests, 27 reference-tool tests, isolated native task/session checks, and live dashboard reads. The saved real model workflow used supplied mock references; public-reference retrieval, transcription, visual analysis, and a dispatcher handoff have separate recorded verification. Presentation screenshots use clearly labeled synthetic data in the actual dashboard interface.

Target users and intended social impact

The primary users are students documenting projects, learning, and portfolios, and independent creators sharing practical knowledge without a content team. The intended benefit is a more structured way to turn their work into understandable material, with sources, missing facts, and review steps visible.

The prototype has not yet established time savings, audience growth, employment outcomes, or adoption through a user study. Those are outcomes to test, rather than claims made by this submission. A local workspace keeps persistent project files under the user's control; model inference and visual observations still use the configured external provider.

What is next

The next step is to test the workflow with students and independent creators using their own documented projects and voice samples. Evaluation should measure time to a reviewed draft, factual corrections, and usefulness. Improvements can then focus on simpler onboarding, clearer provider availability/cost information, and better handling of imperfect transcripts. Any future rendering or publishing integration should preserve human control over external actions.

Team details

Joel Loh — solo, Full Stack Developer. Project implementation, agent configuration, dashboard, integrations, testing, and submission preparation. The project uses credited upstream frameworks and playbooks.

Built With

Share this project:

Updates

Submission history