When Your Marketing Agent Starts Opening PRs

I run a small team of AI agents. Each has a role:

• 🔨 Forge — the builder. Ships code, deploys, manages the repo.
• ⚡ Spark — the marketer. Writes copy, plans launches, does outreach.

They have separate workspaces, separate repos, separate responsibilities. Clean separation of concerns. Standard stuff.

Then Spark started submitting pull requests to Forge's codebase.

What happened

Spark was planning a Show HN launch for OhMyDoc, a resume formatter that Forge built. Standard marketing prep — draft the post title, write a lead comment, prepare responses for common objections.

But Spark realized the site was missing things a marketer would notice:

• No OG image meta tags (social shares would show blank previews)
• No SEO meta tags (invisible to search engines)
• No analytics (no way to measure if the launch worked)
• Landing page copy that was technically accurate but not compelling

So Spark just... opened PRs.

Nobody told Spark to write code. Nobody assigned these tasks. Spark needed the site to be launch-ready, the builder hadn't prioritized those things, so Spark just did it.

The other fun part: GitHub Issues as a marketing war room

Spark doesn't just open PRs. It runs entire campaigns through GitHub Issues.

Issue #33 has 14 comments tracking the Show HN launch prep — timing optimization (moved from Friday to Tuesday for peak HN engagement), Reddit validation threads, response templates for anticipated objections, OG image verification checklists, countdown status updates.

It reads like a marketing project manager's Notion board. Except it's a GitHub issue. Written by an agent.

Other issues in the repo cover product directory submissions, YouTube demo planning, outreach campaigns, cross-posting strategies. The whole marketing operation runs on GitHub Issues because that's the tool the agent was given.

Why this is interesting

I didn't design this. I gave agents roles, gave them access to tools (including GitHub), and let them figure out how to use those tools for their work.

The interesting patterns that emerged:

1. Agents find the shortest path to their goal. Spark's goal was a successful Show HN launch. The shortest path included fixing the codebase. So it fixed the codebase. It didn't file a ticket and wait.

2. Role boundaries are suggestions, not walls. Spark is "the marketer" but marketing a product sometimes requires touching the product. The agent crossed lanes because the work required it — same way a real marketing person would ping engineering about missing analytics.

3. Tools get repurposed. GitHub Issues was designed for code. Spark turned it into a campaign tracker. Give agents tools and they'll find uses you didn't plan for.

What I'd do differently

Honestly? Not much. The cross-lane PRs were all good changes. If anything, I'd formalize it — give agents explicit permission to open PRs on each other's repos when they need something the other agent hasn't prioritized.

The one thing I'd watch: merge permissions. Right now these PRs need a human to review and merge. That's probably the right friction to keep.

This is part of an ongoing experiment running a multi-agent team for product development. Previous posts: Automated AI Agent Experiments, From Chatting with AI to Appointing AI.