Forem: Azamat Safarov

Automating NotebookLM with Hermes Agent: From Research to Multi-Platform Content

Azamat Safarov — Tue, 26 May 2026 10:38:27 +0000

NotebookLM made the writing smarter — analyzing sources, generating podcasts, building visuals. But getting those artifacts out of Google and into my publishing pipeline still took 30 minutes of manual clicking and downloading. I fixed that by wiring NotebookLM directly into Hermes Agent. Now research turns into publish-ready content in about two minutes.

The Problem I Was Solving

NotebookLM is one of the best research tools Google has shipped. Drop in a PDF, a few URLs, or a research query and it builds a notebook — a living summary you can chat with, quiz, or turn into artifacts.

But here is where it breaks for daily publishing. After NotebookLM generates a podcast, a mind map, or a slide deck, you are back to manual mode. Visit the site. Click each artifact. Download. Rename. Move to the right folder. Format for the platform you are posting to. I was spending nearly half an hour on this for every article. The AI did the creative work; I did the file management.

Worse, the standard approach for automating this — browser automation via Playwright — hits a wall. Google detects headless Chromium and Firefox instantly. The login page throws "browser not secure" and you are done. Every automation script I tried failed at authentication.

I needed a way to run NotebookLM from code, download artifacts programmatically, and route them into my publishing pipeline. Hermes Agent already handled the platform distribution. I just needed the bridge.

The Cookie Export Hack That Works

The only authentication method that survived Google's bot detection was exporting cookies from my real Chrome browser. No headless browsers, no Puppeteer tricks. Just real cookies from a real session.

Here is what works reliably:

Log into notebooklm.google.com in your normal Chrome or Edge
Export cookies for domains google.com and notebooklm.google.com as Netscape format using any cookie-export extension
Convert that text file to Playwright's storage_state.json format
The notebooklm-py wrapper reads that state file and gets a valid token

# convert_netscape_cookies.py — one-time setup, reusable
import json, sys, datetime, urllib.parse

netscape_lines = open(sys.argv[1]).readlines()
cookies = []
for line in netscape_lines:
    line = line.strip()
    if not line or line.startswith("#"):
        continue
    parts = line.split("\t")
    if len(parts) < 7:
        continue
    domain, flag, path, secure, expiry, name, value = parts[:7]
    cookies.append({
        "name": name, "value": value, "domain": domain.lstrip("."),
        "path": path, "expires": int(expiry) if expiry.isdigit() else None,
        "httpOnly": "HttpOnly" in flag or "httponly" in flag,
        "secure": "Secure" in flag or "secure" in flag,
        "sameSite": "Lax"
    })

storage = {"cookies": cookies, "origins": []}
with open("storage_state.json", "w") as f:
    json.dump(storage, f, indent=2)
print(f"Converted {len(cookies)} cookies, saved to storage_state.json")

Usage: python convert_netscape_cookies.py exported_cookies.txt

I run this once per session. 23 cookies are enough for full API access. Until Google rotates their auth, this is the only reliable path.

The NotebookLM CLI That Does Everything

Once authenticated, notebooklm-py exposes a clean CLI and Python API. I wrapped this into Hermes skills so the agent can create notebooks, add sources, generate artifacts, and poll for completion without me touching the browser.

Creating a Notebook and Adding Sources

# Create a notebook
python -m notebooklm create "Philosophy Notes"
# → returns notebook ID

# Add sources — URLs, files, research queries
python -m notebooklm source add <notebook-id> https://example.com/article.pdf
python -m notebooklm source add-research <notebook-id> "Stoicism in modern productivity"

Sources can be URLs, local files, Google Drive URLs, or research queries. NotebookLM processes them and builds an indexed knowledge base you can chat with.

Generating Artifacts

Each artifact has its own command and output format.

Artifact	Command	Output	Best For
Audio Overview	`generate audio`	MP3	Podcasts, Telegram voice messages
Infographic	`generate infographic "cover..."`	PNG	Article covers, diagrams, flowcharts
Mind Map	`generate mind-map --instructions "..."`	JSON	Architecture overviews, concept maps
Slide Deck	`generate slide-deck "5 slides..."`	PDF	Presentations, LinkedIn carousels
Quiz	`generate quiz`	Text	Telegram polls, engagement

Note the positional argument for prompts. --prompt does not exist for most artifacts. Infographic, slide-deck, and report accept the description as a positional string. Mind-map only accepts --instructions. Audio accepts a positional topic or nothing — it builds the podcast from your sources directly.

One gotcha: --wait can time out on slow generations (over 60 seconds). I always launch without waiting, get the task ID, then poll separately:

# Launch generation without waiting
python -m notebooklm generate infographic "Dark-themed cover for article about AI research tools, ocean palette" --orientation landscape --style professional --json
# → {"task_id": "...", "status": "pending"}

# Poll in a loop until done
python -m notebooklm artifact poll <task_id>

When the status flips to completed, a Google Cloud Storage URL is returned. I download that asset and route it to the right platform folder.

Wiring It Into the Publishing Pipeline

The full flow in Hermes Agent looks like this:

Source material (markdown, PDFs, URLs)
        ↓
NotebookLM notebook created
        ↓
Sources added → NotebookLM indexes and summarizes
        ↓
Artifacts generated (infographic, mind-map, audio, slides)
        ↓
Hermes downloads, compresses, renames assets
        ↓
Platform-specific routing:
   Dev.to      → full article with embedded infographic
   Telegram    → voice message (audio compressed to 48kbps mono)
   LinkedIn    → carousel from slide deck PDF
   Medium      → essay with timeline / quote cards
   Bluesky     → dense teaser + link to full article
   Mastodon    → threaded summary with cover image

The whole sequence runs as a single Hermes skill. I trigger it with one line: generate notebooklm article for <topic>. The agent creates the notebook, waits for artifacts, downloads them, compresses audio for Telegram's 20 MB limit, and writes platform drafts in parallel.

No more clicking through Google UI. No more drag-and-drop. The AI generates; the pipeline publishes.

A Working Integration Script

Here is the core pattern I use inside the Hermes skill:

from notebooklm import NotebookLMClient
import requests, os, time

client = NotebookLMClient()

# 1. Create notebook
nb = client.create_notebook("Stoic Productivity Analysis")

# 2. Add sources — mix of URLs and research queries
client.add_source(nb.id, source_url="https://example.com/seneca-essay.pdf")
client.add_source(nb.id, source_research="modern applications of Stoic principles")

# 3. Generate cover image (infographic)
cover = client.generate_artifact(
    nb.id,
    artifact_type="infographic",
    instructions="Dark-themed cover image for a technical article about AI-powered research tools. Ocean color palette."
)

# 4. Poll for completion
task_id = cover.task_id
while True:
    status = client.poll_artifact(task_id)
    if status.status == "completed":
        break
    if status.status in ("failed", "error"):
        raise RuntimeError(f"Artifact failed: {status.error}")
    time.sleep(10)

# 5. Download
cover_url = status.url
r = requests.get(cover_url)
open("assets/generated/cover.png", "wb").write(r.content)

# 6. Generate audio podcast
audio = client.generate_artifact(nb.id, artifact_type="audio")
audio_task = audio.task_id
while True:
    status = client.poll_artifact(audio_task)
    if status.status == "completed":
        break
    time.sleep(10)

# 7. Download
audio_url = status.url
r = requests.get(audio_url)
open("assets/generated/podcast.mp3", "wb").write(r.content)

# 8. Compress for Telegram (20 MB limit)
os.system("ffmpeg -i assets/generated/podcast.mp3 -b:a 48k -ac 1 assets/generated/podcast_tg.mp3")

The NotebookLMClient reads the same storage_state.json I built from Chrome cookies. No login step, no browser puppetry. Just API calls against a valid Google session.

Where This Fits in the Larger Stack

NotebookLM is not where content starts — it is where research gets processed. My pipeline already had source material (markdown drafts, PDFs, web pages). NotebookLM adds three things other tools do not:

Audio Overview — two-voice podcast generated from your sources. I drop this straight into Telegram as a voice message. Compression takes a 30 MB raw file down to 7-10 MB. Voices stay clear at 48 kbps mono.
Infographics — article covers and process diagrams generated from a text description. Before this I used Python Pillow locally. It worked, but every cover looked like the same template with slightly different text. NotebookLM generates unique styles per article. I just describe what I want.
Mind Maps — architecture and concept maps that I embed in Dev.to and Medium articles. The output includes node coordinates in JSON, so I can render it or let NotebookLM produce the visual directly.

I still write the original text. I still decide the angle and the argument. But the repetitive work — cover design, audio production, diagram drawing — moved from my desk to the agent's queue.

What Broke Along the Way

Playwright login is dead. Every Chromium and Firefox instance I tried was detected by Google. "Browser not secure" at the login screen, every time. The cookie export method is the only approach that still works.

Wrong prompt syntax. I spent an hour debugging generate infographic --prompt "..." before realizing the flag does not exist. Positional arguments only. For mind-map, use --instructions.

Audio timing. NotebookLM audio generation takes 5-10 minutes. If I use --wait, the CLI sometimes times out after 60 seconds. I now always launch with --json to get the task ID, then poll in a loop until completed.

Image size limits. Bluesky caps images at 2 MB. Raw NotebookLM PNGs are often 2.3-2.8 MB. I run them through ffmpeg for JPEG compression at 800px width before uploading. Yes, ffmpeg — it handles image scaling too.

Results and What Changed

Content production dropped from research plus design plus publishing to research plus about two minutes. The bottleneck is no longer tooling — it is deciding what to write. NotebookLM handles visuals and audio. Hermes handles routing and platform formatting. I handle ideas.

The full pipeline code is open-source:

https://github.com/AzamatSafarov/hermes-notebooklm-bridge

It includes the cookie converter, the one-command pipeline, a Chrome bookmarklet for one-click cookie export, and a working example of Hermes Agent integration. If you are already using Hermes, you can slot it in with two CLI commands and a cookie file.

This whole pipeline runs on the LLM Wiki pattern by Andrej Karpathy — a persistent wiki that the LLM builds and maintains as you go, instead of RAG that re-discovers everything from scratch on every query.

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#file-llm-wiki-md

Dev.to
https://dev.to/azamat_safarov_119e17602f/

Medium
https://medium.com/@akutagorasava777

Paragraph
https://paragraph.com/@azamatsafarov

X
https://x.com/Azamat__Safarov

Building an Autoposting Pipeline with Hermes Agent: Why Waterfall Beats Parallel, and the Edge Cases Nobody Talks About

Azamat Safarov — Mon, 25 May 2026 07:07:31 +0000

I write every day. Distributing to 8 platforms used to take 50 minutes. Now it takes 90 seconds. Here's what I learned building the pipeline, why waterfall beats parallel, and every API trap that almost made me quit.

The Problem

I write every day. For two years, every article ended the same way: open eight tabs, copy the markdown, strip formatting for Telegram, compress images for Mastodon, rewrite the hook for Bluesky's 300-character limit, paste URLs into each platform, log what went where. Fifty minutes of mechanical work after the creative part was done.

The real cost isn't time. It's context switching. After four hours of writing, switching to "platform adaptation mode" feels like starting a second job. You think "I'll distribute tomorrow" and tomorrow you don't remember what the article was about.

I tried Buffer. Tried Zapier. Both fail on the same two fronts: they don't handle markdown-to-plaintext adaptation (Telegram and VK show **bold** literally, not bold), and they don't support Bluesky AT Protocol or Paragraph GraphQL. For niche platforms, custom publishers are the only path.

So I built one. Eight platforms, four pipeline stages, one command.

Architecture: Why Waterfall, Not Parallel

First attempt was naive: blast all platforms simultaneously. Failed immediately.

The issue is dependency chains. Bluesky teasers need the WordPress URL to build link cards — you can't post a teaser before the canonical article exists. Dev.to and Paragraph have rate limits that, when hit in parallel, cascade into 429 storms across all publishers. One platform choking kills the entire run.

Solution: waterfall with selective concurrency. Four stages, each producing artifacts the next stage consumes.

┌─────────────────────────────────────────────────────────────────────┐
│  PIPELINE: WATERFALL WITH SELECTIVE CONCURRENCY                       │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  Stage 1: Content Adaptation (sequential)                           │
│    → Parse markdown source                                          │
│    → Generate platform-specific variants via Jinja2 templates       │
│    → Compress images per platform limits (FFmpeg)                    │
│                                                                     │
│  Stage 2: Primary Hub (sequential, blocking)                        │
│    → WordPress: publish full article → get canonical URL            │
│    → Dev.to: publish markdown variant → get dev.to URL              │
│                                                                     │
│  Stage 3: Social Teasers (parallel, 4 threads)                     │
│    → Bluesky: 300 chars + compressed image + link                   │
│    → Mastodon: 500 chars + media upload + link                      │
│    → Tumblr: photo post + caption + link                            │
│    → Paragraph: markdown + external image URLs + link               │
│                                                                     │
│  Stage 4: Archive (sequential)                                      │
│    → Git commit with all published URLs                             │
│    → Update LLM-Wiki index                                          │
│    → Write execution log for debugging                              │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

Full architecture: LLM-Wiki vault → adaptation → 20+ platforms. Hermes Agent orchestrates each stage.

Why waterfall? Each stage produces artifacts the next stage consumes. WordPress URL becomes the canonical reference for all social platforms. Without it, you're posting orphaned content that disappears in 48 hours.

Stage 1: Content Adaptation

This is where most pipelines die silently. You can't post the same markdown to Dev.to, Telegram, and Bluesky. Dev.to renders ## headers natively. Telegram shows raw # symbols. Bluesky strips all markdown and shows plain text. Each platform needs its own variant.

I built an adaptation layer with Jinja2 templates — one per platform. The source is always the same markdown file in the LLM-Wiki vault. The adapter reads it, applies platform rules, and generates the variant.

# scripts/adaptation.py
import re
from pathlib import Path
from jinja2 import Environment, FileSystemLoader

TEMPLATES_DIR = Path(__file__).parent.parent / "templates"
env = Environment(loader=FileSystemLoader(TEMPLATES_DIR))

def adapt_for_platform(source_md: str, platform: str) -> str:
    """Generate platform-specific variant from canonical markdown."""
    template = env.get_template(f"{platform}.j2")

    # Platform-specific preprocessing
    if platform in ("telegram", "vk"):
        # Strip all markdown — these platforms don't render it
        text = re.sub(r'\*\*(.*?)\*\*', r'\1', source_md)   # bold
        text = re.sub(r'\*(.*?)\*', r'\1', text)             # italic
        text = re.sub(r'__(.*?)__', r'\1', text)            # underline
        text = re.sub(r'~~(.*?)~~', r'\1', text)            # strikethrough
        text = re.sub(r'\[(.*?)\]\((.*?)\)', r'\2', text)   # links → bare URL
        text = re.sub(r'!\[.*?\]\(.*?\)', '', text)        # remove images
        text = re.sub(r'#{1,6}\s+', '', text)              # remove headers
        return template.render(content=text, has_images=False)

    elif platform == "bluesky":
        # 300 graphemes hard limit — distill to hook + detail + URL
        text = re.sub(r'#{1,6}\s+', '', source_md)
        text = re.sub(r'\*\*(.*?)\*\*', r'\1', text)
        text = re.sub(r'\n+', ' ', text)
        # Leave room for URL (~30 chars)
        return text[:270].strip() + "..."

    elif platform == "devto":
        # Markdown-native but SVG doesn't render
        text = source_md.replace(".svg)", ".png)")  # rough SVG→PNG swap
        return template.render(content=text, tags=extract_tags(source_md))

    elif platform == "wordpress":
        # Full HTML conversion for WordPress REST API
        return template.render(content=markdown_to_html(source_md))

    elif platform == "mastodon":
        # 500 chars, no markdown
        text = re.sub(r'\*\*(.*?)\*\*', r'\1', source_md)
        text = re.sub(r'\n+', ' ', text)
        return text[:470].strip() + "..."

    elif platform == "paragraph":
        # Markdown accepted, but images must be external URLs
        return template.render(content=source_md, images_are_external=True)

    return source_md  # fallback

def extract_tags(md: str) -> list:
    """Extract tags from YAML frontmatter, limit to 4 for Dev.to."""
    match = re.search(r'^tags:\s*(.+)', md, re.MULTILINE)
    if match:
        tags = [t.strip() for t in match.group(1).split(",")]
        return tags[:4]  # Dev.to hard limit
    return ["python", "automation"]

Platform rules (hard-won through failure):

Platform	Markdown	Images	Length Limit	Special Rules
Telegram / VK	Strip all	External URL previews only	~4000 chars	Bare URLs for previews, no markdown
Bluesky	Strip all	Blob upload (2MB max)	300 graphemes	Must count graphemes, not bytes
Mastodon	Strip all	Two-step media upload	500 chars	`POST /api/v1/media` → `id` → `POST /api/v1/statuses`
Dev.to	Native	Must be PNG (SVG breaks)	None	4 tags max, draft mode available
WordPress	HTML	External URLs only (free plan)	None	`posts` scope only, no `media`
Paragraph	Native	External URLs only	None	GitHub raw URLs hotlink-blocked

The adaptation stage takes ~30 seconds — reads source, applies all rules, writes 8 variants. Each variant is git-versioned.

Stage 2: Primary Hub — WordPress & Dev.to

Two platforms publish first. Both produce URLs that downstream platforms need.

WordPress is the SEO anchor. Every social teaser links back to it as canonical source. Social platforms are not indexed by Google; WordPress is. Without it, you're posting orphaned content.

# api/publishers/wordpress.py
import os
import requests

ACCESS_TOKEN = os.environ.get('WORDPRESS_ACCESS_TOKEN')
BLOG_ID = os.environ.get('WORDPRESS_BLOG_ID')

def publish_post(title: str, content: str, featured_image_url: str = None,
                 categories: list = None, tags: str = "") -> dict:
    url = f"https://public-api.wordpress.com/rest/v1.2/sites/{BLOG_ID}/posts/new"
    headers = {
        "Authorization": f"Bearer {ACCESS_TOKEN}",
        "Content-Type": "application/json",
    }
    payload = {
        "title": title,
        "content": content,
        "status": "publish",
    }
    if categories:
        payload["categories"] = categories
    if tags:
        payload["tags"] = tags
    if featured_image_url:
        payload["featured_image"] = featured_image_url

    r = requests.post(url, headers=headers, json=payload, timeout=30)
    data = r.json()

    return {
        "success": "ID" in data,
        "url": data.get("URL"),
        "id": data.get("ID")
    }

Critical limitation: Free WordPress.com plans only grant posts OAuth scope. media scope requires paid plan. Cannot upload images via API on free tier. Workaround: host images externally and reference by URL.

Dev.to is the technical hub. Markdown-native, code blocks work, frontmatter tags auto-categorize. The Dev.to URL becomes the "also published on" link.

# api/publishers/devto.py
import os
import requests

API_KEY = os.environ.get('DEVTO_API_KEY')

def publish_article(title: str, body: str, tags: list, published: bool = False) -> dict:
    url = "https://dev.to/api/articles"
    headers = {
        "api-key": API_KEY,
        "Content-Type": "application/json"
    }

    payload = {
        "article": {
            "title": title,
            "body_markdown": body,
            "published": published,
            "tags": tags[:4]  # Dev.to hard limit: 4 tags max
        }
    }

    r = requests.post(url, headers=headers, json=payload, timeout=30)
    data = r.json()

    if r.status_code == 201:
        return {"success": True, "url": data.get("url"), "id": data.get("id")}
    return {"success": False, "error": data.get("error", f"HTTP {r.status_code}")}

Invisible limits discovered:

4 tags maximum. Sending 5 returns 422 "Tag list exceed the maximum of 4 tags".
SVG images don't render. Dev.to's CDN doesn't process SVG. Convert to PNG via FFmpeg before upload.
Draft mode: published: false creates a draft visible in your dashboard. You review, then hit "Publish" manually.

Both must complete before Stage 3 starts. If WordPress fails, the pipeline halts.

Stage 3: Social Teasers — Parallel

Once WordPress and Dev.to return URLs, four social platforms fire in parallel.

Bluesky: AT Protocol Is Not REST

Bluesky doesn't use REST. It uses AT Protocol — binary blob uploads, record creation via JSON-RPC, 2MB blob size limit.

# api/publishers/bluesky.py
import os
import requests
from datetime import datetime, timezone

HANDLE = os.environ.get('BLUESKY_HANDLE')
APP_PASSWORD = os.environ.get('BLUESKY_APP_PASSWORD')
BASE_URL = "https://bsky.social/xrpc"

def create_session() -> dict:
    r = requests.post(
        f"{BASE_URL}/com.atproto.server.createSession",
        json={"identifier": HANDLE, "password": APP_PASSWORD},
        timeout=30
    )
    data = r.json()
    return {
        "success": "accessJwt" in data,
        "accessJwt": data.get("accessJwt"),
        "did": data.get("did")
    }

def upload_blob(image_path: str, session: dict) -> dict:
    ext = image_path.lower().split(".")[-1]
    mime = {"jpg": "image/jpeg", "jpeg": "image/jpeg", "png": "image/png", "gif": "image/gif"}.get(ext, "image/png")

    with open(image_path, "rb") as f:
        data = f.read()

    r = requests.post(
        f"{BASE_URL}/com.atproto.repo.uploadBlob",
        headers={
            "Authorization": f"Bearer {session['accessJwt']}",
            "Content-Type": mime
        },
        data=data,
        timeout=120  # 1.5MB uploads need time
    )

    blob = r.json().get("blob")
    return {"success": bool(blob), "blob": blob}

def post(text: str, image_path: str = None) -> dict:
    session = create_session()
    if not session["success"]:
        return session

    now = datetime.now(timezone.utc).isoformat().replace("+00:00", "Z")

    record = {
        "$type": "app.bsky.feed.post",
        "text": text,
        "createdAt": now,
    }

    if image_path and os.path.exists(image_path):
        if os.path.getsize(image_path) > 2_000_000:
            compressed = image_path.replace(".png", "-compressed.jpg")
            os.system(f"ffmpeg -y -i {image_path} -q:v 2 {compressed}")
            image_path = compressed

        blob = upload_blob(image_path, session)
        if blob["success"]:
            record["embed"] = {
                "$type": "app.bsky.embed.images",
                "images": [{"alt": "", "image": blob["blob"]}]
            }

    r = requests.post(
        f"{BASE_URL}/com.atproto.repo.createRecord",
        headers={"Authorization": f"Bearer {session['accessJwt']}"},
        json={
            "repo": session["did"],
            "collection": "app.bsky.feed.post",
            "record": record
        },
        timeout=30
    )

    data = r.json()
    if "uri" in data:
        post_id = data["uri"].split("/")[-1]
        return {
            "success": True,
            "url": f"https://bsky.app/profile/{HANDLE}/post/{post_id}"
        }
    return {"success": False, "error": data}

Three traps in this code:

uploadBlob expects raw bytes with Content-Type header — not multipart files={...}. requests.post(..., data=bytes, headers={"Content-Type": "image/png"}) — not files={"image": open(...)}.
Default 30-second timeout is too short for 1.5MB uploads. Increased to 120 seconds after three consecutive failures.
300-grapheme limit is hard. len(text) counts codepoints; Japanese emoji counts as multiple grapemes. Must use regex.findall(r'\X', text) for accurate counting.

Mastodon: Two-Step Media

Mastodon requires separate media upload before status creation.

# api/publishers/mastodon.py
import os
import requests

BASE_URL = os.environ.get('MASTODON_URL')
ACCESS_TOKEN = os.environ.get('MASTODON_ACCESS_TOKEN')

def upload_media(image_path: str) -> dict:
    url = f"{BASE_URL}/api/v1/media"
    headers = {"Authorization": f"Bearer {ACCESS_TOKEN}"}

    with open(image_path, "rb") as f:
        files = {"file": (os.path.basename(image_path), f)}
        r = requests.post(url, headers=headers, files=files, timeout=60)

    data = r.json()
    return {
        "success": "id" in data,
        "id": data.get("id"),
        "url": data.get("url")
    }

def post_status(text: str, media_ids: list = None) -> dict:
    url = f"{BASE_URL}/api/v1/statuses"
    headers = {"Authorization": f"Bearer {ACCESS_TOKEN}"}
    payload = {"status": text}
    if media_ids:
        payload["media_ids[]"] = media_ids

    r = requests.post(url, headers=headers, data=payload, timeout=30)
    data = r.json()

    return {
        "success": "id" in data,
        "url": data.get("url")
    }

Single-call status creation with both text and file does NOT work. Must be two requests.

Tumblr and Paragraph follow similar patterns — media upload first, then post creation with media IDs or external URLs.

Stage 4: Archive & The Orchestrator

Hermes Agent schedules tasks but never autopublishes without explicit approval.

# scripts/orchestrator.py
import sys
from pathlib import Path
from concurrent.futures import ThreadPoolExecutor

sys.path.insert(0, str(Path(__file__).parent.parent))

from api.publishers.bluesky import post as publish_bluesky
from api.publishers.wordpress import publish_post as publish_wordpress
from api.publishers.devto import publish_article as publish_devto
from api.publishers.mastodon import post_status as publish_mastodon, upload_media as upload_mastodon_media
from api.publishers.paragraph import publish_post as publish_paragraph
from scripts.adaptation import adapt_for_platform

def run_pipeline(article_path: str, image_path: str, dry_run: bool = True):
    with open(article_path) as f:
        full_text = f.read()

    # Stage 1: Adaptation
    variants = {
        "wordpress": adapt_for_platform(full_text, "wordpress"),
        "devto": adapt_for_platform(full_text, "devto"),
        "bluesky": adapt_for_platform(full_text, "bluesky"),
        "mastodon": adapt_for_platform(full_text, "mastodon"),
        "tumblr": adapt_for_platform(full_text, "tumblr"),
        "paragraph": adapt_for_platform(full_text, "paragraph"),
    }

    if dry_run:
        print("[DRY RUN] Platform variants generated:")
        for platform, text in variants.items():
            print(f"  {platform}: {len(text)} chars")
        return

    # Stage 2: Primary Hub (sequential, blocking)
    wp = publish_wordpress({
        "title": "Article Title",
        "content": variants["wordpress"],
        "status": "publish",
        "categories": ["Productivity", "Tools"],
        "tags": "automation, python, publishing, hermes"
    })
    canonical_url = wp.get("url")

    dev = publish_devto({
        "title": "Article Title",
        "body_markdown": variants["devto"],
        "published": False,  # Draft for review
        "tags": ["python", "automation", "publishing", "hermes"]
    })

    # Stage 3: Social Teasers (parallel, 4 threads)
    def publish_bluesky_trailer():
        text = f"{variants['bluesky']} → {canonical_url}"
        return publish_bluesky(text, image_path)

    def publish_mastodon_trailer():
        media = upload_mastodon_media(image_path)
        text = f"{variants['mastodon']} → {dev.get('url', canonical_url)}"
        return publish_mastodon(text, [media["id"]] if media["success"] else [])

    def publish_tumblr_post():
        # Tumblr API: photo post with caption
        return publish_tumblr(image_path, variants["tumblr"], canonical_url)

    def publish_paragraph_article():
        return publish_paragraph("Article Title", variants["paragraph"])

    with ThreadPoolExecutor(max_workers=4) as executor:
        futures = {
            "bluesky": executor.submit(publish_bluesky_trailer),
            "mastodon": executor.submit(publish_mastodon_trailer),
            "tumblr": executor.submit(publish_tumblr_post),
            "paragraph": executor.submit(publish_paragraph_article),
        }
        social_results = {k: v.result() for k, v in futures.items()}

    # Stage 4: Archive
    log_publish_results(wp, dev, social_results)
    git_commit_with_urls(wp, dev, social_results)
    update_llm_wiki_index(wp, dev, social_results)

Human-in-the-loop design:

User says "publish this article"
Agent generates all variants, shows previews
User reviews Dev.to draft (most complex variant)
User says "confirmed" — only then API calls execute

This prevents the "oh no I just live-posted a draft" panic. Every publisher has dry_run=True default.

Failure handling: If Bluesky fails, the pipeline logs the error, continues with remaining platforms, reports partial success:

Bluesky: FAILED (blob > 2MB)
WordPress: SUCCESS — https://azamatsafarov.wordpress.com/...
Dev.to: SUCCESS (draft) — https://dev.to/...
Mastodon: SUCCESS — https://mastodon.social/@...

Edge Cases: The Real Curriculum

Edge Case	How I Discovered It	The Fix
Bluesky blob > 2MB	Three consecutive failures Thursday evening, all 400 with no error body	FFmpeg compression: `ffmpeg -y -i input.png -q:v 2 output.jpg`
WordPress free plan blocks media upload	403 on every image upload, docs say "check token scope"	Host images externally, reference by URL
Dev.to SVG broken	Pipeline diagram showed empty box for a week	`ffmpeg -y -i diagram.svg diagram.png` in adaptation stage
Dev.to 5th tag rejected	Got 422, read error, realized the limit	Hard truncate to 4 tags. No negotiation
Mastodon two-step media	Posted text without image three times	Two separate requests: `POST /api/v1/media` → `id` → `POST /api/v1/statuses`
Bluesky 300 graphemes	Posted 305-char teaser, got `"record too large"` with no details	Grapheme counting via `regex.findall(r'\X', text)` before posting
Paragraph hotlink blocking	GitHub raw URLs showed as broken images	VK CDN URLs from `photos.getById` after VK upload
LinkedIn token expires	Posts failed with 401 after 60 days	Manual refresh. Not worth automating for monthly posting
Markdown divergence	Telegram showed `bold` literally, VK showed raw brackets	Strip all markdown for Telegram/VK in adaptation stage
NotebookLM cookies expire	Cron job ran at 11:00, failed silently at auth	Two-step cron: 10:30 reminder → user pastes cookies → 11:00 publish

Results: What Actually Changed

Metric	Before Pipeline	After Pipeline
Time per article	50 minutes (8 platforms × ~6 min each)	90 seconds (automation) + 5 min review
Platforms covered	3–4, depending on energy	8 automated + drafts for 10 more
Failed uploads	~30% (forgot image, wrong format, expired token)	~5% (token expiration only)
SEO indexing	None — social content ephemeral	WordPress as canonical, indexed by Google
Context switching	8 tabs, 8 different UIs, 8 copy-paste operations	One command, one preview, one approval
Article versioning	None — distributed copies diverged	Git tracks every variant, platform, URL

The biggest change isn't speed. It's consistency. Before the pipeline, I distributed to 3–4 platforms depending on how tired I was. The pipeline makes 8 platforms the default. Energy-independent.