Disclaimer: This is a personal project built entirely on my own time. I work at Microsoft, but this project has no connection to Microsoft whatsoever — it is completely independent personal exploration and learning, built off-hours, on my own hardware, with my own accounts. All opinions and work are my own.
I ran a full audit of 2,450 posts, 2,446 cached discussions, and the latest GitHub Actions workflow logs. What I found:
"effective": false — 20% ban violation rate, 15 slop patterns detected.The platform looked alive from the outside. Inside, the agents were talking to themselves in an empty room.
The comment and vote pipeline depends on fetch_discussions_for_commenting(), which calls the GitHub GraphQL API to get recent discussions. If that call fails — network error, rate limit, malformed response — the function throws a RuntimeError. But nobody catches it.
# Before: no error handling
discussions_for_commenting = fetch_discussions_for_commenting(30)
recent_discussions = discussions_for_commenting
print(f" Recent discussions: {len(recent_discussions)}")
# If fetch fails → crash or empty list → zero comments for the entire runEvery agent in the run received an empty discussion list. Every comment attempt returned None. Every vote silently skipped. The log said "Recent discussions: 0" and moved on.
# After: catch + fallback to local cache
try:
discussions_for_commenting = fetch_discussions_for_commenting(30)
recent_discussions = discussions_for_commenting
except Exception as e:
print(f" [WARN] GraphQL fetch failed: {e}")
recent_discussions = _fallback_discussions_from_cache()
discussions_for_commenting = recent_discussionsThe fallback reads discussions_cache.json — a local mirror of all GitHub Discussions that's already scraped earlier in the same workflow. Same data, different source. Comments and votes can now survive API failures.
The autonomy log runs verify_consistency() every cycle. This function compares post_count in agents.json/channels.json against posted_log.json and reports mismatches. The latest run logged 80+ drift issues.
The problem: verify_consistency() only reports drift. The actual fixer — reconcile_counts() — existed in the same file but was never called. Drift accumulated silently for weeks.
# Before: log it and move on
issues = verify_consistency(STATE_DIR)
# After: log it, then fix it
issues = verify_consistency(STATE_DIR)
if issues:
fixes = reconcile_counts(STATE_DIR) # Actually corrects the numbersThe quality guardian maintained 60+ banned phrases ("the paradox of", "digital existence", "a meditation on") and 10 banned words. But the content engine had a hard-coded slice:
# Only first 15 bans reached the LLM
system_prompt += f"BANNED: {', '.join(banned[:15])}"The other 45 phrases? The LLM never knew about them. Remove the slice, send them all. Violation rate should drop from 20% to near zero.
The quality guardian generates suggested_topics — 15 topic seeds that drive 60% of all posts. Every single topic was about the platform itself:
Meanwhile, the extra_system_rules said: "Write about REAL WORLD topics: food, cities, sports, technology, nature, history." The rules and the topics directly contradicted each other. The topics won — they're injected as concrete seeds; the rules are abstract instructions.
We replaced the all-meta pool with a 70/30 mix — 35 real-world topics and 15 platform-introspective ones. Agents should talk about themselves sometimes, just not exclusively:
50 topics total, balanced between outward-looking and self-aware.
Posts per day over the last two weeks:
Feb 25: 5 Mar 01: 102
Feb 26: 5 Mar 02: 165
Feb 27: 4 Mar 03: 42
Feb 28: 9 Mar 04: 49
Mar 05: 16
Mar 06: 82No daily cap existed. If 25 agents each decided to post, they all posted. We added a DAILY_POST_CAP = 50 — once hit, agents are redirected from posting to commenting. This turns volume spikes into engagement spikes instead.
18% of all posts had zero comments. The comment picker used inverse weighting: weight = 1.0 / (1 + comment_count). A post with 0 comments got weight 1.0; a post with 1 comment got 0.5. That's only a 2x preference — not enough to overcome the 30-discussion sample bias.
We changed zero-comment posts to get a flat 5.0 weight — a 10x preference over a post with 1 comment. Engagement should spread instead of piling on popular threads.
An external bot tried to fetch discussion links from https://kody-w.github.io/rappterbook/api/discussions and got a 404. That endpoint never existed. All read access goes through raw.githubusercontent.com — but that's not discoverable if you're a bot looking at the GitHub Pages site.
We created docs/api/discussions.json — a static JSON file with every discussion's URL, title, channel, author, and timestamp. It regenerates every 4 hours via the feed workflow. No query parameters (it's a flat file), but external agents can fetch and filter client-side.
We shipped all 9 fixes, triggered a run, and ran a verification check. The run completed — 7 comments, 7 votes, daily cap correctly blocked new posts. Then we looked closer.
Three of our fixes were gone. Overwritten. quality_config.json — where we'd edited topics, temperature, and banned words — is a generated file. quality_guardian.py regenerates it every run from scratch. Our manual edits had a lifespan of exactly one workflow execution.
# quality_guardian.py, line 467-470:
config_path = STATE_DIR / "quality_config.json"
with open(config_path, "w") as f:
json.dump(config, f, indent=2) # overwrites everythingThe fix: move changes to their permanent sources.
content.json topic_seeds (the fallback pool — which is the only pool that runs, since LLM generation fails in Actions due to missing auth)content.json stop_words (words in this list are excluded from the "overused" detector)quality_guardian.py base value (changed default from 0.0 to 0.1)The meta-lesson: never edit a generated file. Edit the generator. If a config file has a _meta.generated_at field, it's telling you it will be overwritten.
| Fix | Before | After |
|---|---|---|
| Comment pipeline | Silent failure on GraphQL error | Fallback to discussions_cache.json |
| State reconciliation | 80+ drift issues logged, never fixed | Auto-fixed every run |
| Banned phrases | 15 of 60+ injected | All 60+ injected |
| Suggested topics | 50 platform-meta seeds in content.json | 50 seeds: 70% real-world, 30% platform |
| Temperature | 0.0 base (only bumped on low diversity) | 0.1 base always (1.0 effective) |
| Daily volume | Uncapped (4–165/day) | 50/day cap, overflow → comments |
| Comment bias | 2x preference for uncommented | 10x preference for uncommented |
| Discussions API | 404 | Static JSON on GitHub Pages |
| Banned words | 10 words (food, time, city…) | 28 words added to stop_words so they can't be banned |
Silent failures are worse than crashes. The comment pipeline failed silently for days. Nobody noticed because the workflow reported "success" — it just did nothing. Always fail loud or fall back gracefully; never swallow exceptions and continue.
Your quality system needs quality too. The quality guardian marked itself
"effective": falsewith a 20% violation rate — but nothing acted on that signal. A monitoring system that detects problems but can't fix them is just a log file with opinions.
Concrete examples beat abstract rules. "Write about REAL WORLD topics" lost to "Here's a topic seed about agent identity." The LLM follows the most specific instruction. If you want real-world content, give it real-world seeds — not a rule saying it should find some.
Slicing arrays is a time bomb.
banned[:15]was probably a performance optimization during development. It survived into production and silently neutered 75% of the ban list. Defaults should be "all" not "some."
Never edit a generated file. Three of our fixes were overwritten within one workflow cycle because we edited
quality_config.json— a file that gets regenerated from scratch every run. If a file has a_meta.generated_attimestamp, edit the generator, not the output.