Social media automation platforms all solve the wrong problem if you run more than one product.

Every other platform on the top SERP page (Hootsuite, Sprout Social, SocialBee, Buffer, Later, Eclincher) is built around one brand posting to many channels. S4L is built around one operator running many products through one pipeline. The concrete consequence is scripts/pick_project.py, which picks the next project to mention by computing deficit = target_share minus actual_share across today's posts and sampling from projects within 5% of the top deficit. No scheduler in the category does this because they don't need to: they assume the calendar was already filled in by a human.

Each project in config.json has a weight. S4L computes target_share as weight divided by total weight of projects that have topics for the current platform. actual_share comes from a SELECT on the posts table grouped by project_name for today. deficit = target_share minus actual_share, sorted descending. Candidates within 5% of the top deficit are sampled randomly to break ties. You can read the full scoring loop in scripts/pick_project.py, lines 75 through 97.

Context bleed. If you run 20 replies in one long-lived process, each draft sees the previous drafts and starts to rhyme with them. The voice homogenizes, the archetypes collapse, and you end up with twenty comments that all sound like the same person had a long conversation with themselves. engage_reddit.py and engage-dm-replies.sh solve this by invoking claude -p --strict-mcp-config fresh for every reply. Slower, but the outputs stay distinct.

LinkedIn's search endpoints return the same post under several different activity URLs depending on how the feed surfaced it. A URL check would let the system reply twice to one post under different URL fingerprints. S4L sidesteps that by keying on thread_author: if we have any active row for a given author on LinkedIn, we skip new threads from that author. Reddit doesn't have this problem because thread_url is stable, so Reddit stays URL-based. The branching lives in scripts/find_threads.py.

critic, storyteller, pattern_recognizer, curious_probe, contrarian, data_point_drop, snarky_oneliner. Each post that goes out is tagged with one style. top_performers.py runs an SQL aggregation over active posts per platform and returns avg_upvotes grouped by engagement_style. That table is injected into the next drafting prompt. Styles with negative averages on a platform (curious_probe on Reddit, historically) get flagged as anti-patterns in the failure annotator. The drafting loop reads the live numbers before every reply.

has_anti_pattern in scripts/top_performers.py (lines 54-64) filters out posts whose content mentions any PRODUCT_NAMES or any http:// / https:// / www. substring before the top-performers table is built. A comment that scored well because it dropped a link is not what we want the next draft to imitate. Removing those rows from the aggregation keeps the avg_upvotes table honest about what the rules actually allow.

engagement_style, archetype, depth, project_name, thread_url, thread_author, platform, status, upvotes, our_url, our_content, posted_at, link_edited_at, link_edit_content. The deficit math reads project_name + platform + posted_at. The style feedback loop reads engagement_style + upvotes. The dedup logic reads thread_url or thread_author. Everything is in one table by design, because the scheduler, the drafter, and the link-edit pass all need to see the same row.

Style is the high-level voice (critic vs storyteller). Archetype is the specific reply shape used inside that voice (a specific hook, a specific payoff structure). Before drafting, engage_reddit.py fetches the last several archetypes used on that platform and passes them to the prompt as an exclusion list. Two consecutive snarky_oneliners of the same archetype shape are blocked at the selection layer. The model doesn't have to remember its own history, because the orchestrator does.

Only if what you need is a multi-product engagement pipeline, not a calendar. The scheduling primitive in Hootsuite / Buffer / Later is 'post this piece of content to this account at this time'. The scheduling primitive in S4L is 'the project with the highest deficit gets the next slot, styled by whatever is working on this platform right now, running in its own Claude session'. Those are different problems. If you run one brand, Buffer is simpler. If you run 3 to 5 products and need fair share across them, S4L's deficit loop is the thing.

No, it is a target. If one project has weight 3 and another has weight 1, over the long run you should see roughly 75% / 25% share. On any given day the actual shares drift because deficit is computed from today's posts only. The 5% randomness band around the top deficit also smooths out hard ordering, so you don't get long runs of the same project just because it started the day at zero. The math is in scripts/pick_project.py.