I built an AI content repurposer in a weekend. The first version returned 4 identical outputs.RocketRide gave me the perfect output

TrishaReddygari — Sun, 03 May 2026 19:16:04 +0000

I built an AI content repurposer in a weekend. The first version returned 4 identical outputs.

I'd been meaning to automate content repurposing for months. Every time I publish a long-form post, I end up rewriting the same idea four different ways for LinkedIn, X, dev.to, and Instagram. Each platform wants a different shape, a different attention budget, a different tone. Mechanical work. Boring work. The kind of work where, by the fourth platform, I'm just paraphrasing myself badly.

Last weekend I sat down to build it. I picked RocketRide — an open-source, developer-native AI pipeline tool — instead of writing a Python script with four LLM calls glued together. The whole thing ended up being one 14-component .pipe JSON file, no orchestration code, four GPT-4o calls running in parallel. It works.

But the first version didn't.

This post is about the design mistake I made on attempt one, why it produced four identical outputs instead of four platform-specific ones, and the one-node-type swap that fixed it. Plus what I learned about RocketRide along the way.

What I built (the working version)

A pipeline that takes one long-form blog post and produces four platform-native variants:

A LinkedIn post (under 1,300 chars, hook + insight + soft question, no hashtags)
An X thread (5–8 numbered tweets, ≤280 chars each)
A dev.to article (markdown with TL;DR + 3 takeaways + CTA)
An Instagram caption (800–1,500 chars, conversational, with hashtags)

Architecture:

                    ┌─→ agent(LinkedIn)  → GPT-4o ──┐
                    │                                │
                    ├─→ agent(X thread)  → GPT-4o ──┤
chat (paste post) ──┤                                ├─→ response (4 outputs)
                    ├─→ agent(dev.to)    → GPT-4o ──┤
                    │                                │
                    └─→ agent(Instagram) → GPT-4o ──┘

One source feeds four parallel chains. Single response node collects all four outputs. The four LLM calls run in parallel, so the total latency is roughly one GPT-4o call, not four.

Full code: github.com/TrishaReddygari/rocketride-content-repurposer

Version 1 returned four identical outputs

For my first cut, I used four prompt nodes (one per platform) sandwiched between the source and the LLMs. Each prompt had careful platform-specific instructions: "Rewrite as a LinkedIn post, max 1,300 chars, no hashtags, end with a soft question." That kind of thing.

I ran the pipe. Four LLM calls, four answers came back.

All four outputs were essentially the same generic blog summary. Same title ("Building an AI Content Repurposer with RocketRide: Key Insights"). Same numbered sections. None of them under 1,300 chars. None of them shaped like a tweet thread. None of them with hashtags.

I'd written four different platform prompts and the LLM had ignored every one of them.

Why prompts didn't work

The prompt node in RocketRide is designed for RAG-style context injection. You feed it documents + a question, it merges them into one blob, and hands the blob to the LLM. The LLM treats the merged content as background to consider, not rules to obey. My platform-specific instructions were getting injected as context — the LLM read them, interpreted them as "topics this article is about," and produced a generic summary that touched on all of them.

This is a category of mistake I'd missed in their docs but probably should have caught: prompt is for what to think about, not how to behave.

The fix: agent nodes

RocketRide's agent_rocketride node treats instructions as a real system prompt — the LLM is told "you are a LinkedIn-rewriter agent, follow these rules, do not deviate." It's not background context, it's the agent's role.

I replaced the four prompt nodes with four agent_rocketride nodes (each with its own LLM and memory_internal sidecar — agents need both). Same input, same prompts, same source post.

Re-ran the pipe.

The LinkedIn output came back at 995 characters with a punchy hook line and a soft closing question. The X thread output came back as eight numbered tweets, every one under 280 chars. The dev.to output was actual markdown with a TL;DR blockquote and three bullet takeaways. The Instagram output had emoji, casual line breaks, and a row of hashtags at the end.

One node-type swap. Everything else stayed the same.

Three things that surprised me about RocketRide

The .pipe JSON file is the right level of abstraction. Most AI workflow tools force you to pick: visual canvas (which is then a nightmare to version-control) or pure code (which gives up the visual debugging). RocketRide pipelines are plain JSON files that live in your repo and git diff cleanly — and the same JSON renders as a visual canvas when you open it in their VS Code extension. I wrote my pipe by hand in a text editor because their docs were good enough that I didn't need the canvas. The canvas is right there for screenshots, debugging, and onboarding teammates.

Lane-typing catches mistakes at validation, not runtime. Components in RocketRide connect via typed lanes (text, questions, answers, documents, image). You can't accidentally wire a text output into a questions input — the engine refuses. The category of bug where your LangChain pipeline silently produces empty strings because of a wrong field name is structurally impossible. After enough hours debugging that exact class of bug elsewhere, this felt like a quiet luxury.

COMMON_MISTAKES.md is the best single document I've read in any OSS AI tool. RocketRide ships a 1,400-line ROCKETRIDE_COMMON_MISTAKES.md that reads like someone debugged a hundred broken pipelines and decided to short-circuit the entire support cycle. Two of its rules saved me real time on this build. (The one I missed about prompt vs agent nodes? It wasn't in there. I should probably open a PR adding it.)

What's next

The next step for the repurposer is swapping the chat source node for a webhook source — so the pipe runs automatically when I publish a new post via my CMS, instead of me pasting into a chat panel. That's a one-node change in the .pipe file. The four agents and the LLM fan-out stay exactly the same.

The deeper thing I'm taking from this build: small, single-purpose, version-controlled AI pipelines beat one-giant-agent architectures for production work. The repurposer does one specific thing, lives in a .pipe file, fits in 14 components. RocketRide bets on that shape, and I think they're right.

Full pipe and README at github.com/TrishaReddygari/rocketride-content-repurposer. MIT-licensed. Copy it. Swap the LLM. Add a fifth platform. Wire it to your own publishing flow.

DEV Community: TrishaReddygari