fog is the open source marketing AI agent stack swanbase built for early-stage founders. Five agents, the AGENT.md format, portable across Claude Code, Cursor, Codex CLI and Gemini CLI. Apache 2.0.
Marketing AI agents: fog, the open source stack swanbase built for founders

Marketing AI agents: how fog, the open source stack built by swanbase, works

A founder chasing their first hundred users shouldn't have to hire. They should be able to launch five marketing agents from their terminal, read the results ten minutes later, and move on to the next decision. That's the conviction that produced fog.

fog (Founders Growth agents) is the open source marketing AI agent stack that swanbase released in 2026 under the Apache 2.0 license. Five agents, one shared spec format (AGENT.md), a common CLI toolbelt, and the same philosophy everywhere: an agent does one thing, in one chat, and you can read it in two minutes. The pack is portable across Claude Code, Cursor, Codex CLI and Gemini CLI. Official site: fog-agents.com. Full technical playbook: marketing-agents-playbook.

This guide explains what a marketing AI agent has become in 2026 (spoiler: not a robot, a folder of markdown), why the vertical format beats the mega-agent, and how fog structures each of the five agents we're opening to the founder community today.

fog-agents.com, the fog stack homepage

Why we built fog (for founders)

The market for marketing AI agents in 2026 looks like this: closed SaaS products selling you "ready-to-use agents" at 200 euros a month, agencies billing you 5,000 euros to wire three prompts into a Notion, and a handful of open source frameworks built for AI engineers, not for founders who just want to move forward.

None of these tools were designed for a founder's real pattern in the early stage. The real pattern is: "I need, right now, to understand what users are actually saying about my segment. I want to launch this analysis in two minutes and read the result before my next meeting." Not "I want to configure a Zapier workflow to publish three posts a week."

We wrote fog because we wanted, for swanbase, a stack that answers exactly that pattern. Five agents that cover a founder's bottlenecks in the phase from 0 to 1000 users. Open source so other founders can fork them, and so the AGENT.md spec can become a standard that nobody owns.

What a marketing AI agent actually is in 2026 (an operational definition)

Forget the sci-fi

A marketing AI agent in 2026 is not a robot. It's not a proprietary cloud service. It's not a ChatGPT in disguise.

It's a folder of markdown files.

A folder of markdown your harness reads

Concretely, when you install a fog agent on your machine, you end up with a structure like this:

agents/
└── market-signal/
    ├── AGENT.md              ← human- and machine-readable spec
    ├── README.md             ← prerequisites, install
    ├── config.example.json   ← config template
    └── assets/
        └── output-template.md ← deliverable skeleton

You point your AI harness (Claude Code, Cursor, Codex CLI or Gemini CLI) at the folder and write in natural language:

"Run the market-signal agent at agents/market-signal/.
Market: freelance invoicing tools for designers."

The harness reads the AGENT.md, asks you for any missing inputs in chat, runs the workflow step by step (shell commands, CLI calls, LLM reasoning), and writes the deliverable into your project folder. No daemon. No SDK. No runtime to babysit.

The agent is portable because it's just text. No vendor lock-in. You run the same AGENT.md on Claude Code today and on Cursor tomorrow, without touching a line.

Agent vs chatbot vs prompt vs skill

Four concepts that often get conflated, four different functions:

Concept Form Output When to use it
Prompt One sentence Variable One-shot question, instant answer
Chatbot Open conversation Variable Brainstorming, exploration
Agent Structured workflow (AGENT.md) Predictable format, every time Repeated task with a formatted deliverable
Skill Reusable subtask (SKILL.md) Block shared across agents When 3 agents share the same piece of code

A marketing agent is what lets you say "I want this deliverable, in this shape, every time" and be guaranteed to get it, no matter who launches the command, no matter the harness, no matter the weather.

The anatomy of an AGENT.md (the 6 parts)

Anatomy of an AGENT.md file: the 6 parts of a marketing AI agent

Every well-built AGENT.md has six parts. The format wasn't invented for fog; it crystallized naturally from building dozens of internal agents at swanbase before we open-sourced the stack.

1. Frontmatter

---
name: market-signal
description: Reads what real users say about a market before you write copy
compatibility: claude-code, cursor, codex, gemini
---

A machine-readable header. It lets a harness preload the agent without reading the whole file. Three fields are enough.

2. When to run

One to three sentences a founder can read in five seconds. Before validation. When traffic drops. Before paying for paid. Each line is a concrete trigger, not a theory.

3. Inputs needed

A table of required vs optional inputs, with defaults. The agent has to refuse to start if a required input is missing. Most of the failures we saw in the wild came from skipped inputs.

| Input | Required | Default | Example |
|---|---|---|---|
| market | yes | n/a | "freelance invoicing tools for designers" |
| language | no | en | fr |
| depth | no | standard | quick / standard / deep |

4. Workflow

Numbered steps. Each step is ≤ 6 lines. Each step uses shell, a toolbelt CLI, or LLM reasoning. No magic, no opaque function.

5. Output

A markdown skeleton, or a link to a template in assets/. The agent has to produce this exact shape on every run. The predictability of the output is what makes the deliverable trustworthy.

6. Failure modes

What to do when a CLI is missing, when an API returns nothing, when a step times out. The fallback is explicit. Silent degradation is the most efficient way to kill trust in an agent.

Why six parts? Predictability is a feature. A founder who has never seen the stack should be able to scan any AGENT.md in thirty seconds and know what it does, what it needs, what it produces. If you can't, the agent isn't finished.

Vertical agents vs mega-agent (the real debate)

Everyone's talking about skills. The dominant pattern is a mega-AGENT.md with fifty skills bolted on, every helper, every persona, every CLI wrapper crammed into the same context. We think that's wrong.

Our thesis is the opposite. Every fog agent is a vertical folder, small, that does one thing, opened in its own chat, with only the context that job needs. The agent is small enough to read in one session, focused enough that the model doesn't drift, and self-contained enough that you can switch harnesses without rewiring.

The rule. If two agents share work, that's a candidate for a skill. If an agent runs past a few hundred lines of AGENT.md, that's two agents. Resist the natural gravity toward the mega-agent. Vertical agents stay sharp. Bloated agents get lost in their own context.

See Claude Code vs Cursor compared to understand why the harness shapes how much context depth you can manage.

The 5 agents in the fog stack

Here are the five agents that make up fog today. Each one solves a concrete founder bottleneck. You run them on-demand, at the moment the bottleneck shows up on your path.

market-signal

When to run it. Before you write a single line of copy or code. Reads what real users are saying on Reddit, X, niche forums, and Hacker News about your target market.

Inputs. market (required: "freelance invoicing tools for designers"), language (default en), geography (default global), depth (quick · standard · deep).

Output. A markdown report with a sentiment breakdown, top issues by mention count, a psychographic profile, 15 to 20 sourced verbatim quotes, and three actionable recommendations.

Underlying conviction. Don't guess what users feel. Read what they wrote.

first-users

When to run it. When you're hunting for your first 10 to 50 users and you don't know where they hang out.

Inputs. product (required), target_user (required), geography (optional).

Output. A map of relevant channels (subreddits, Slack/Discord communities, X threads, specialized forums, events) with first-message templates tailored to each channel. CLIs used: exa-cli, firecrawl-cli.

seo-audit

When to run it. When traffic drops. A one-shot SEO snapshot. Combines Google Search Console data + a live SERP crawl + a prioritization of the fixes.

Inputs. domain (required), gsc_property (required), language (default en), time_range (default 90d).

Output. A list of pages losing traffic, the keywords involved, the current SERP state, and the list of prioritized fixes (impact × effort). CLIs used: gsc, firecrawl-cli.

landing-page-analyzer

When to run it. Before you spend on paid. Or after launch when conversion stalls. A heuristic CRO audit against the LEVER framework (Legibility · Enticement · Value clarity · Evidence · Resistance).

Inputs. url (required), goal (required: "book a demo"), target_user (required: "B2B sales ops leads"), context (optional), language (default en).

Output. A LEVER scorecard, the 10-second test result, 30+ heuristic findings tagged pass/issue/critical, top 5 ship-this-week fixes ranked by impact × ease, three rewritten headlines, and 3 to 5 A/B test hypotheses.

Underlying conviction. Don't pay for traffic into a leaky bucket.

cold-outreach-builder

When to run it. When you're ready to move to targeted outbound. Builds a sequence of 4 to 6 messages with per-prospect personalization. Cialdini-grounded.

Inputs. target_audience (required), value_prop (required), prospect_list (CSV), tone.

Output. A complete email sequence ready to load into Instantly, with per-prospect personalized hooks, a psychological justification for each persuasion lever used, and a follow-up plan. CLIs used: exa-cli, firecrawl-cli, instantly-cli.

Plus the _template-agent template you can fork to build your own.

The Marketing Agents Playbook, the full technical guide to fog on fog-agents.com

→ Read The Marketing Agents Playbook on fog-agents.com/marketing-agents-playbook (the long version, with line-by-line examples).

The cli-skills toolbelt (the real infra)

The fog data flow in 4 steps: founder, harness, agent, cli-skills toolbelt

Marketing agents need to do things: search the web, scrape pages, query Google Search Console, push outreach campaigns. The naive method is to code those calls into each agent. That's exactly what you shouldn't do.

Instead, fog installs a shared toolbelt of CLIs and each agent reaches it through a simple shell-out. The public toolbelt is cli-skills:

# One-shot install, reusable by every fog agent
git clone https://github.com/the20100/cli-skills.git ~/cli-skills

# Add to PATH
export PATH="$HOME/cli-skills/exa-cli/bin:$PATH"
export PATH="$HOME/cli-skills/firecrawl-cli/bin:$PATH"

# API keys required by each CLI
export EXA_API_KEY="..."
export FIRECRAWL_API_KEY="..."

market-signal can now shell-out to exa-cli search … without bundling the SDK. seo-audit can call gsc query …. cold-outreach-builder can pipe to instantly-cli push …. Three agents, one toolbelt, zero duplicated code.

It's the same pattern as the /usr/local/bin folder on Unix: you install once, the whole system uses it. No proprietary SDK in every agent. No duplication. No version drift between agents.

A fog agent's deliverable lands in your repo instead of a SaaS: versioned markdown, structured JSON

On the way out of the toolbelt, fog agents write their results as text files in your project folder. You commit, you diff, you revisit them a month later. No proprietary UI, no platform holding your data hostage. That's what changes everything compared to classic marketing AI agent SaaS.

How to build your first marketing AI agent (a 4-step method)

If you want to build your own agent (beyond fog's five), here's the method we follow at swanbase.

Step 1: fork the _template-agent

The template ships inside the fog repo. It defines the contract every agent has to satisfy: an AGENT.md skeleton, a README with prerequisites, config.example.json, assets/output-template.md, and references/ for the API docs. Not runnable, just a skeleton to copy.

cp -r agents/_template-agent agents/my-new-agent
cd agents/my-new-agent

When you build your fourth marketing agent, you'll appreciate that the first three look alike.

Step 2: fill in the six parts of AGENT.md

Frontmatter, when-to-run, inputs, workflow, output, failure modes. If you get stuck on any of the six, read the marketing agents playbook, which walks through each part with examples.

Step 3: test on all four harnesses

Run the same AGENT.md on Claude Code, Cursor, Codex CLI and Gemini CLI. If a harness fails, a portability rule is broken (see the next section). Fix it and rerun.

Step 4: iterate on the output

The output is what makes an agent reliable or not. Run the agent ten times across varied cases. Compare the outputs against each other. If the shape drifts, your output template is too loose and you need to tighten the spec. If the shape holds but the content is weak, it's your workflow that's under-specified.

The typical iteration cycle: 30 minutes of writing, 30 minutes of testing on 5 cases, 30 minutes of patching. Three hours for a production agent. Compare that with the weeks it took to ship an AI agent to production a year ago, see Claude Managed Agents: the complete guide.

The 3 portability rules (Claude Code marketing agents)

A marketing agent is portable when it works identically on Claude Code, Cursor, Codex CLI and Gemini CLI. That portability is fragile. Three rules keep it intact.

Rule 1: no calls to a harness's proprietary functions

No mcp__*, no claude-*, no function that exists only in one harness. Anything you can't express in bash + cli-skills has no place in the agent.

That's exactly why proprietary Claude Code marketing agents (which depend on an Anthropic MCP server, for example) only work on Claude Code and nowhere else. A truly portable marketing AI agent has to be written to the smallest common denominator: shell + CLI.

Rule 2: no hardcoded absolute paths

The agent always works from the root of the user's project, which it receives as input. It doesn't know where it lives on disk. No /Users/<you>/Documents/.... No /home/founder/agents/.... Always paths relative to the project root.

Rule 3: the output goes outside the agent's folder

Deliverables are written to <project>/<agent-name>/<label>-<YYYYMMDD>.md. The agent's folder stays clean and pullable. You can update the agent without risking overwriting your deliverables.

Three rules, three lines of doctrine. Follow them and your agent runs the same on every harness. Skip them and you lock yourself to one harness and break fog's promise.

The 2 non-negotiables we stand by

Beneath every agent in the stack sit two convictions that are simpler to write than to embody.

"Don't guess what users feel. Read what they wrote."

Kills the urge to invent user pain from a whiteboard. It's the market-signal agent that turns this principle into systematic reading of Reddit, X, forums and HN before a single line of copy.

"Don't pay for traffic into a leaky bucket."

Kills the urge to launch paid before the page deserves it. It's the landing-page-analyzer agent that turns this principle into a systematic LEVER audit before every ad spend.

Build agents that enforce these two disciplines, and your stack does most of a junior marketer's job, on-demand, for the cost of an API call. That's the whole bet behind fog. For broader context on growth marketing in startups, see growth marketing for startups.

fog vs the alternatives (agency, SaaS, DIY)

A quick comparison of the four approaches available to a founder who wants to solve their marketing bottlenecks.

Criterion Freelance agency Marketing agents SaaS DIY (from scratch) fog
Monthly cost 2-5K € 100-500 € Founder's time API costs (~50-100 €)
Time to first deliverable 2-4 weeks 1 day 2-3 weeks 30 minutes
Auditable No No (black box) Yes Yes (readable markdown)
Modifiable No Limited Yes Yes (direct fork)
Portable across harnesses N/A No Depends on implementation Yes (by design)
License Contract Subscription You own it Apache 2.0
Fit for a founder at 0-1000 users Oversized Too generic Too costly in time Built for it

For the tools founders use daily at swanbase beyond fog, see free tools for founders and Claude Code vs Cursor.

How to start now

fog is on fog-agents.com. Apache 2.0 license, free, modifiable. You can:

  1. Read the marketing agents playbook: the long version of this article, with concrete examples on the anatomy of an AGENT.md, the toolbelt pattern, and three agents detailed line by line.
  2. Install the cli-skills toolbelt: the infra layer shared by every agent. Fifteen minutes of setup.
  3. Run your first agent: market-signal is the simplest. Pick a market you know, run it on Claude Code, read the report. Thirty minutes from clone to first decision.

If you build a marketing agent that could join the public stack, write to us. fog grows at the rate that founder bottlenecks appear.

FAQ

What is a marketing AI agent, concretely? A marketing AI agent in 2026 is a folder of markdown files (AGENT.md, README, config) that an AI harness like Claude Code, Cursor, Codex CLI or Gemini CLI can read and run. That folder describes, in plain language, the required inputs, the step-by-step workflow to follow, the expected output format, and the failure modes. The harness reads the AGENT.md, runs the shell commands or CLI calls listed in the workflow, and writes the deliverable into the founder's project folder. There's no daemon to keep running, no proprietary SDK, no runtime to maintain.

What's the difference between an agent, a chatbot and a prompt? A prompt is a one-shot instruction sent to the model. A chatbot is an open conversation where the model responds to messages with no predefined plan. An agent follows a structured workflow, described in an AGENT.md, with typed inputs, ordered steps, and a deliverable in a predictable format. The key difference: an agent produces the same shape of output on every run, no matter who launches it. A chatbot improvises. A prompt is too short for that.

Do you need to know how to code to use fog? No. fog is designed to be used in natural language through an AI harness. You open Claude Code, Cursor, Codex CLI or Gemini CLI, point at the agent (for example: "Run agents/market-signal/ for the freelance invoicing tools market"), and the harness reads the AGENT.md, asks you for any missing inputs in chat, runs the commands, and writes the deliverable. Being able to read markdown and install a CLI is enough. If you want to modify an agent or build one, a little Bash helps.

What's the monthly cost to run fog? The fog code is free (Apache 2.0). The costs come from the AI harness and the third-party CLIs used by the cli-skills toolbelt. Budget for a Claude Pro subscription or Anthropic API access for Claude Code (20 dollars a month on pro, or usage-based billing), plus the optional CLIs depending on the agents you run: Exa (semantic web search), Firecrawl (scraping), Perplexity (search Q&A), Instantly (cold email). A founder who runs market-signal and landing-page-analyzer once a week gets by on under 100 dollars a month, infrastructure included.

Which AI harnesses does fog support? fog is portable by design. The agents run on Claude Code (Anthropic), Cursor, Codex CLI (OpenAI) and Gemini CLI (Google). Portability is guaranteed by three strict rules: no calls to a harness's proprietary functions, no hardcoded absolute paths, and all outputs are written outside the agent's folder. You can run the same AGENT.md on Claude Code today and on Cursor tomorrow without changing a line.

How long does it take to fit fog into your flow? Thirty minutes for the first setup: clone the cli-skills repo, export three API keys (Exa, Firecrawl, Serper), point the harness at the agent's folder and run a first command. From there, each additional agent takes ten seconds (point and run). The typical adoption curve: one agent a day during the first week, then integration into your decision rhythm (before validation, before paid traffic, after launch, and so on).

Why is fog under Apache 2.0 and not a commercial license? Three reasons. First, an agent that makes a founder's marketing decision has to be readable, auditable and modifiable. A closed license blocks that transparency. Second, the AGENT.md format only becomes a standard if everyone can use, extend and fork it without asking permission. Apache 2.0 permits commercial use, forking and derivation, as long as attribution is kept. Third, we build fog for our own use at swanbase first. Open source is a virtuous side effect, not a product to sell.

Does fog replace a marketing agency? For a founder in the phase from 0 to 1000 users, yes. The five agents cover the recurring bottlenecks of that phase. Beyond that, when you need to run a content team, manage six-figure paid, or orchestrate a yearly editorial calendar, an agency stays relevant. fog doesn't replace a senior CMO. It replaces the freelance agency you were about to pay 3K a month to do what you could have launched yourself in fifteen minutes.


fog is created and maintained by swanbase, the Paris-based startup accelerator. Our usage insights on AI agents come from our own internal stack and the programs we support. To dig into related concepts, see also open source alternatives to AI agents and what Claude Code is.