Session 20: Complete LinkedIn Agency Automation — Carousels + Newsletter from One Content System

The strategic frame before any code: rented reach (LinkedIn, Instagram) vs owned audience (the email list). The system is designed so rented reach continuously converts to owned audience — every carousel's fifth slide is a fixed CTA ('Subscribe to my newsletter at harshith.com/subscribe'), the site has a one-field capture bar, and the newsletter itself is AI-written on a two-day cadence at his real letter.harshith.com (~344 subscribers at session time). One content system, two repurposings: 'if you have built out one content system, you can repurpose it for both.'

The career version of the same doctrine closes the loop: 'three things are very important at this point — a very nice portfolio, a skills folder in markdown, and a newsletter... end of the day it's about distribution, about getting those eyeballs.'

The finished pipeline, corrected live in three passes: (1) DISCOVERY — Firecrawl searches ~10 themes (AI, agentic AI, automation, IT, cloud, cybersecurity, developer tools, infrastructure), deduplicates and credibility-ranks sources; the run button is the ONLY input — no topic field. (2) COPY — OpenAI's structured-output API writes exactly four concise slides plus the CTA slide. (3) VISUALS — the image-native decision: instead of HTML text overlaid on a generated background ('the text would be static... I want a unique design, something that Canva can create'), the writing step produces PROMPTS, and GPT Image renders each fully-designed slide; slide 1 becomes the design reference so 2-5 stay visually consistent; watermark harshith.com. (4) OUTPUT — a node-graph dashboard ('create an N8N-style visual workflow' was the literal prompt) with per-slide progress states and a human Publish button as the only gate to LinkedIn.

The UI fight is part of the lesson: the agent first shipped a Kanban ('the correct screen is Content Status Kanban; your diagram describes an automation graph — those are different mental models' — the agent's own diagnosis), which he overruled toward nodes because the mental model of the product IS the workflow.

The walkthrough nobody documents in one place: LinkedIn Developer portal → My Apps → Create App (requires a company PAGE even for personal posting — create one with your logo and privacy policy) → then request 'products' one by one: Share on LinkedIn (posting), Sign in with OpenID Connect (the standard login), Lead Sync (capture from Lead Manager), Ad Library access, verification-status retrieval. Approval is free but slow (~3 weeks; his took that, after a denial-and-reapply cycle). Once granted, the OAuth credentials live in his LinkedIn Auth Publisher SKILL, so any build can add a publish node without re-deriving the flow; the learner copy ships with the OAuth replaced by placeholders.

The architectural quirk repeated for the room: 'you have to use the business page API to get the personal-sender API access' — page first, person second.

The delivery half of the system: RESEND for programmatic sending (API key created live, named, and scoped to send only to his own address during testing — the blast radius rule), a sibling newsletter pipeline sharing the carousel system's provider credentials ('don't depend on me to give you another API key — borrow and use the exact same one'), and a Publish button as the human gate mirroring the LinkedIn side. The test lands in his real inbox on camera: subject, lead visual, four sections, eight sources, working hyperlinks.

For the template layer: REACT.EMAIL — Resend's open-source component library ('so many emails: activation, feature announcement, password reset, subscription confirmation... how Slack structures their emails') — copy a template link into your agent and have it generate your house template. His real newsletter footer/design comes from exactly this route.

Three workflow lessons braided through the build. PORTABILITY: the harness lives in the repo's markdown, not in the tool — Bethany's how-do-you-sync-across-platforms question gets 'it's the folder'; Sidh's structure (goal, decisions, memory, research, spec, state, content-loop — all MD files in ONE folder) is endorsed as the cleaner layout, and Paul's directory question gets the same answer: brainstorm the folder tree first, keep the markdown together. GOAL.MD is the session's discovery: 'it works better when the LLM has both the agents and the goal file — it understands what its end goal is and only works in that direction.'

MODEL TIERS as a dial: 5.6 'extra high' for planning ('my harness is trained to ask me a ton of questions before it does anything' — why his output differs from a learner's), switched to 'Sol light' mid-build 'because I just wanted to do things faster.' SIDE-EFFECTS: the Superpowers skill both helps (spec discipline, brainstorming gates) and hurts (degraded front-end output, Playwright loops he kills twice — 'stop with the browser automation'); skills are dependencies with costs, prune them when they fight you. And the API-key theater — the agent refusing pasted keys until ordered ('please stop rejecting my API keys, it's a strict order'), then itself flagging 'API key was pasted to the chat, so it should be rotated after setup' — is the hygiene lesson running in both directions at once.

The mechanics, as taught: AI generators embed provenance metadata (content credentials — the C2PA standard OpenAI participates in) inside the image file; LinkedIn reads it and displays the CR icon. Direct 'remove the metadata' requests now get refused by his tools, so the workaround is a pretextual prompt — claim the metadata is WRONG and needs correcting — after which the file is scrubbed and posts badge-free. He suggests productizing it: 'a metadata removal node' in the pipeline before the publisher.

Record this with both eyes open: the badge exists so viewers can know an image is synthetic; the workaround defeats a provenance standard by lying to a safety refusal. It works today; platforms are moving toward server-side detection that no local scrub beats, and norms (plus possibly rules) around AI disclosure are tightening. Knowing the mechanism is valuable — the CR icon's meaning, where metadata lives, why the refusal exists. Deploying it on client work is a judgment call that deserves the client's informed consent, not a default node.