What is a content operating system?

A content operating system is a code-based infrastructure for creating, distributing, and compounding content across platforms. Instead of a content calendar or spreadsheet, you build voice rules, platform playbooks, and production pipelines in version-controlled files.

Voice DNA is the foundational layer of the 3-tier system. It encodes your cadence, vocabulary, anti-patterns, and identity markers into files that AI agents read before generating any content. Same voice, every platform, every time.

How do platform playbooks work?

Each platform gets its own playbook that inherits from your Voice DNA. The LinkedIn playbook knows paragraph structure, emoji usage, and CTA patterns. The TikTok playbook knows 16-second structures and hook formats. Same voice, different container.

How does the recursive feedback loop work?

Every published post teaches the system. Performance data feeds back into voice rules. When the anti-slop guide catches a new pattern, it gets added. When a hook style outperforms, it gets documented. The 100th post is easier than the 1st.

Can I build my own Content OS?

Absolutely. The wiki, how-to guides, and method page document the entire system. Start with Voice DNA (who you are), add platform playbooks (how you adapt), then build content ops (how you ship). Everything here is public.

$ man content-wiki/chatbot-architecture

Tools and MCPsintermediate

How the NeoBots Work

Soul files, RAG scoring, and the ChatWidget pattern behind Nio, Rem, and Recon

by Shawn Tenam

Three Bots, One Pattern

Each site in the GTMe OS monorepo ships its own chatbot: Nio on shawnos.ai, Rem on thecontentos.ai, Recon on thegtmos.ai. They share the same ChatWidget component from the shared package but each has a distinct personality, knowledge base, and accent color. The bots are public-facing - no auth required - and exist to help visitors explore the wiki, blog, and knowledge base content on each site.

PATTERN

Soul Files and System Prompts

Each bot's personality is defined in its API route's system prompt. The prompt sets the tone (lowercase energy, direct, no fluff), the persona (Nio talks like a builder, Rem like a content strategist, Recon like an ops engineer), and the rules (only answer from provided context, never fabricate URLs, link to full articles). The system prompt is assembled at request time by injecting retrieved article content below the rules block. This means the bot's knowledge is always current with the wiki - no retraining needed.

PATTERN

RAG Retrieval Without a Vector DB

The bots use keyword-based retrieval instead of embeddings. Each wiki entry, knowledge term, and blog post is converted into a RetrievableItem with title, description, keywords, and truncated content. When a user sends a message, the retrieval engine scores every item against the query using keyword overlap, synonym expansion, and category matching. The top 5 results are injected into the system prompt as context. A synonym map per bot expands queries - asking about 'cold email' also matches 'outbound', 'sequence', and 'prospecting'. This approach is fast, deterministic, and costs zero infrastructure.

PRO TIP

The ChatWidget Component

All three bots render through a single ChatWidget component in the shared package. It handles the chat UI, message streaming, suggested questions, gating (Substack subscribe or CTA), and the floating bubble. Each site passes its own config: bot name, accent color, welcome message, suggested questions, and API endpoint. The avatar (animated APNG) is rendered separately by each site's wrapper component (NioChat, RemChat, ReconChat) with a slide-in animation when the chat opens.

← content wiki knowledge guide →