If you're building an AI product for content channels, you'll hit one question sooner or later: how do you configure AI behavior without making the user spend hours on parameters?
Most approaches: "enter N, get result." Simple, but doesn't work because channels aren't uniform. At PersonymAI we solved this through inversion — AI studies the channel first, then proposes settings based on what it found.
Let me walk through how it works and why this architecture is more than a UX improvement — it's a shift in interaction model with the AI system.
THE PROBLEM WITH ABSTRACT PARAMETERS
Imagine a SaaS for AI comments. Classic approach:
- "Comments per post: [5]"
- "Tone: [casual/professional]"
- "Profanity level: [low/medium/high]" User sits there, looks at these parameters, doesn't know what to set. Because the effect of parameters is abstract — they can't see how exactly they'll affect comments under their actual posts. Result: user sets defaults, gets mediocre output, unhappy, churns. THE TOPIC DISCOVERY APPROACH Instead of giving the user parameters, we give the AI the channel. User clicks one button → AI fetches the last 100 posts from the channel through specialized Telegram accounts → classifies content into topics → returns 8-15 topics with examples from the user's actual content. User sees NOT "category A, category B" but specific topics from their channel like "BTC technical analysis" with three examples of real posts. They immediately understand what's at stake. THREE BUCKETS AS A CONTROL ABSTRACTION Instead of 50 parameters — three buckets:
- "Allowed" — AI works automatically
- "Ask in DM" — AI messages user before each post in this topic
- "Denied" — AI ignores This covers 95% of real scenarios and takes 30 seconds per channel. User thinks in risk categories ("VIP promo is risky — ask," "technical analysis is safe — allow"), not abstract numbers. DUAL-LEVEL QUANTITY CONTROL For allowed topics there's need for quantity control. Architecture here has two levels:
- Global channel range (e.g., 5-30)
- Per-topic override (e.g., topic "jokes" = 3-5) Per-topic override is an optional extension of global settings. If user didn't touch a specific topic, it uses the global range. Key constraint: per-topic max cannot exceed global channel max. This is enforced at UI level (input.max attribute) and on blur commit (math clamp). If user later lowers the global, all per-topic overrides that exceed automatically clamp. This isn't just validation, it's a system invariant: channel-max is a hard ceiling user sets with one number, then local adjustments below that ceiling. Safe and predictable. UI DETAILS WORTH MENTIONING On mobile we use bucket-move buttons instead of drag-and-drop. Drag&drop on touch conflicted with native scroll and caused lag. Sticky save bar has logic to hide on input focus — otherwise iOS keyboard overlaps the Save button. 3 locales (EN/RU/UA) for global market. Markdown in example posts renders Telegram-style (bold/italic/links). CONCLUSION Topic Discovery isn't a feature, it's an inversion of the interaction model. Instead of "user explains to AI what they need" — "AI explains to user what it found in their channel and proposes a reaction." It's not a panacea, but for content-AI it works better than the classic approach with abstract parameters. How does your SaaS solve the problem of configuring AI for user specifics? Drop a comment. https://personym-ai.com
Top comments (0)