AI-Enabled Growth Operating System
An AI-enabled growth operating system spans brand voice, ideal customer profile (ICP), channel playbooks, and quality review. It is built and run solo across three brand repositories, each version-controlled and synced from a canonical detector. Cycle time was cut by 50%, and output stayed consistent across three voices.
Problem
Three brands ran from a single team, each with a distinct audience, channel mix, and growth motion. Atrium Academy teaches DeFi developers through a partner program called Uniswap Hook Incubator. LevelUp Labs distills a problem-first approach for AI practitioners. Learn Prompting trains engineers and enthusiasts on AI usage. Content quality varied by author. Brand voices drifted across pieces. ICP work lived in whoever had the most context that week. The team needed to ship more, and alignment was the bottleneck.
Approach
I built three layers in sequence, all version-controlled.
- Brand Voice DocumentationEach brand has one foundation. The foundation names the voice principles, the tone rules, the vocabulary preferences, and the writing standard for what each brand specifically sounds like. Drift is easier to catch when preferred patterns are explicit.
- Claude Skill LibraryRepeatable marketing operations tasks are codified as reusable skills. ICP research starts from a subscriber sample. Positioning drafts start from a product brief. Channel-specific copy adaptation takes the same message and reshapes it per channel, starting with X, LinkedIn, and email.
- Quality Review PipelineEvery draft runs through three checks before publication. The checks are brand voice alignment, writing standard adherence, and overall quality review.
The system improves the longer it runs. Each shipped piece teaches the next one, each market signal sharpens the ICP, and each rejected draft refines the detector.
Architecture
The system has one canonical repository and three brand repositories that inherit from it. Edits to the detector happen in the canonical repository and propagate to the others, so no drift between copies. The canonical detector enforces the same quality bar across every brand under Atrium, while each brand's own voice files preserve its distinct identity.
Uniswap operates as a partner program under Atrium Academy, but maintains its own repository because it has distinct voice, ICP, and workflows from the parent brand.
Each brand repository follows the same internal structure.
Each repository is self-contained, so a teammate can clone one and run the same operating system without any outside dependencies. The quality review gate is baked into every skill, so the workflow refuses to ship if the detector is missing, and brand voice drift is caught before publication.
How the system works
Every piece of publishable content runs through the same pipeline.
-
01LoadBrand foundation loads with voice rules, ICP, and the writing standard.
-
02Identify ICPTargeted ICP is required before drafting. Generic content is disallowed.
-
03DraftSkill drafts against the brand's writing standard.
-
04DetectAI writing detector loops until the draft scores 100%.
-
05ShipOutput saves tagged with channel, ICP, KPI, and status.
See the demo
Uniswap is the demo brand because it is recognizable outside the Atrium ecosystem. The public demo shows the structure. The production system is significantly larger across every layer.
- Updates to the detector sync automatically to all four production repositories.
- The reference library is five to ten times larger, fed by deeper ICP research and ongoing customer interviews.
- AI-based stylistic scoring measures each draft against samples of the brand's authentic voice.
- The detector is retuned weekly to keep up with AI model drift.
- Prompts update based on what's actually performing in market.
Content is the test case. The same pattern applies to launch playbooks and lifecycle messaging. The operating system, not the deliverable, is the point.
What I would do differently
I built the brand voice documents first and the quality review second. That was the wrong order. The quality review caught patterns the documents had missed, which meant rewriting the voice documents while they were already in use. If I built the system again, I would build the quality review first against a small sample of existing content, then write the voice documents to match what it enforces. The quality review shapes the documents, not the other way around.