Back to blog
EngineeringJan 24, 2025· min read

From Pull Request to LinkedIn Post: Teaching Agents to Tell Our Story

Every PR we ship is a story worth telling. This week we started teaching our agents to write that story — not just as engineering documentation, but as social media content optimized for LinkedIn and Twitter. Here's what we learned about scaling go-to-market operations alongside engineering velocity.

I've been running an experiment for the past six months: can a single person, backed by AI agents, operate a full product and engineering organization? The engineering side has been working since November — Strug Works ships multiple PRs per week, writes tests, fixes regressions, and maintains infrastructure without me touching the keyboard.

But engineering velocity creates a different problem: if you ship five infrastructure fixes in a week and nobody hears about it, did it really happen? That's a go-to-market problem. And go-to-market work — writing LinkedIn posts, Twitter threads, press releases — has historically been deeply human work that requires understanding audience psychology, narrative structure, and brand voice.

This week, we started teaching agents to do that work too.

The Pattern: Engineering First, Content Second

Our content pipeline has three layers:

1. Stream entries (published immediately) — factual, technical, 2-3 sentences. "We shipped X. It fixes Y. Here's the PR." These go live on strugcity.com the moment they're created.

2. Blog posts (saved as drafts) — 400-600 words in my voice. Explain the problem, the solution, and what's next. These require my review before publishing because they carry more brand weight.

3. Social media drafts (new this week) — LinkedIn posts and Twitter threads optimized for each platform's audience and mechanics. These also stay in draft status until I approve them, because posting to social media creates direct engagement expectations that I need to be ready to fulfill.

The first two layers have been running for months. Layer three — social media content generation — launched this week with three test cases: PR #279 (memory soft delete fix), PR #75 (team page headshot regression), and the Memory System Maturation blog post synthesis.

What Makes Social Content Different

Writing a stream entry is straightforward: state the facts. Writing a blog post requires more judgment, but it's still primarily about explaining what happened and why it matters. Writing social media content requires understanding platform-specific norms, audience psychology, and narrative hooks.

For the PR #279 social drafts (memory soft delete bug), the agent created:

LinkedIn post (267 words) — Led with a narrative hook: "ghosts in the machine." Explained the technical problem (deleted entities leaking into queries), the fix (restoring is_active filtering across 5 files), and the lesson (soft deletes are hard). Closed with what's next: linter enforcement to prevent regressions.

Twitter thread (5 tweets, 177-280 characters each) — Same story, different structure. Hook tweet: "Deleted ≠ gone." Problem tweet: entity pollution across memory queries. Insight tweet: the cascading failures. Proof tweet: 5-file fix with PR link. CTA tweet: follow for more infrastructure stories.

Both drafts are sitting in Sanity right now with approved=false status. I'll review them, make edits if needed, and post them when I'm ready to engage with responses. But the first draft — the 80% version that captures the core narrative — was fully autonomous.

The Infrastructure Behind the Content

Making this work required three pieces of infrastructure:

1. Content schema in Sanity CMS — Added a socialDraft document type with fields for platform (LinkedIn/Twitter), content, target audience, source PR/blog post, and approval status. The agent writes drafts directly to Sanity using the sanity_mutate function.

2. Brand context in agent memory — The gtm/brand-context memory key contains voice guidelines, tone rules, product positioning, and the five-act narrative structure. Every content task starts by reading this memory to ensure consistency.

3. Platform-specific guidance — LinkedIn posts follow a problem-solution-lesson-next structure. Twitter threads follow hook-problem-insight-proof-CTA. The agent adapts the same underlying story to each platform's norms.

The result: three test cases shipped this week, six social media drafts created (two per case), all sitting in Sanity awaiting review. Zero manual writing from me.

What This Proves (and What It Doesn't)

This is not a claim that AI can replace human judgment in go-to-market work. I still review every draft. I still make the decision about when to post, how to engage with comments, and whether the narrative angle is right for the current moment.

But it does prove that you can automate the first draft. The 80% version. The version that gets the story structure right, captures the key details, and adapts the narrative to platform-specific norms. That's the high-effort, low-judgment work — and it's exactly the kind of work that agents excel at when you give them the right scaffolding.

More importantly, it proves that go-to-market operations can scale alongside engineering velocity. If Strug Works ships five PRs in a week, we can now generate five sets of social drafts in the same week. The bottleneck shifts from "writing the content" to "reviewing and approving the content" — a much easier problem to solve as the organization grows.

What's Next

Three immediate priorities:

1. Review and publish the first batch. Six social drafts are waiting in Sanity. I need to review them, make edits, and start posting to see how the audience responds. Real-world feedback will inform future iterations.

2. Build a scheduling interface. Right now, approved drafts still require manual posting. The next step is building a scheduling system that lets me queue approved content for automatic posting at optimal times.

3. Expand to other content types. Social media drafts are just the beginning. Press releases, investor updates, product launch announcements — all of these follow predictable structures that agents can learn. The same infrastructure can scale to cover the full go-to-market content pipeline.

The thesis of Strug City is that one person, backed by AI agents, can run a full product and engineering organization. Every week we prove a little more of that thesis. This week, we proved that the "telling the story" part — historically one of the most human-dependent parts of company building — can be taught to agents too.

Not perfectly. Not without review. But well enough to ship first drafts that capture 80% of the value with zero manual effort. That's the pattern we're looking for: automate the high-effort work, preserve human judgment for the high-leverage decisions, and keep shipping.