u/exto13

One problem with agent-driven publishing: side effects are hard to make

reliable. An agent calls publish, the network drops at channel 4 of 8,

and now you don't know what landed.

content-distribution-mcp is designed around that constraint.

Every publish call is idempotent on (content_id, channel). The server

tracks state in a backend (YAML or Notion) and skips channels that

already succeeded. A retry is always safe — the agent can call publish

again without checking what completed.

The Reddit pre-flight is the other interesting piece from an agent

reliability standpoint. Reddit's moderation is probabilistic and account-

damaging if you get it wrong. Rather than let the agent fire and hope,

the server runs all checks locally first:

- Cooldown per subreddit

- 5/day global submission cap

- Self-promo ratio for the subreddit

- Required flair presence

If any check fails, the tool returns a structured error with the reason.

The agent gets a clear signal, not a silent moderation removal days later.

The server makes zero LLM calls. The agent layer handles copy generation;

the server handles I/O, state, and error recovery. Clean separation.

8 channels: DEVto, Hashnode, GitHub Discussions, Bluesky, Reddit,

Medium, LinkedIn, Twitter.

pip install content-distribution-mcp

I've been running a workflow that turns one Notion task into a planned, model-tiered, parallel-dispatched pipeline with a human approval gate. Sharing the pattern in case it's useful.

The pattern

1. Operator submits a single high-level task in Notion ("launch the pricing page", "run a Q2 outbound campaign").
2. A planner agent reads the task and emits a subtask graph: each subtask gets a description, dependencies, and an explicit model assignment (Opus / Sonnet / Haiku).
3. The plan lands back in Notion as child pages. Operator reviews, edits, or rejects.
4. On approval, an orchestrator dispatches subtasks in parallel where the graph allows, sequentially where it doesn't. Each subtask runs on its assigned model.
5. Outputs come back to the same Notion task tree for review.

Concrete artifact: a website launch decomposed

One submitted task, 21 subtasks across three model tiers:

• 1 Opus task: information architecture + content outline
• 4 Sonnet tasks (parallel): page copy drafts
• 6 Haiku tasks (parallel): asset/image generation prompts
• 10 Haiku tasks (parallel): directory submission entries

One operator approval click. 21 outputs back in Notion.

Why per-task model assignment matters

Defaulting to the smartest model for every subtask is the easiest way to burn money on agentic workflows. In practice, routing clerical work (formatting, submission, simple drafts) to Haiku and reserving Opus for reasoning-heavy steps cuts model spend roughly an order of magnitude on workflows like this, with no quality loss on the parts that matter.

Validation notes

• The approval gate is load-bearing. Without it the planner occasionally misjudges scope or invents subtasks. With it, those get caught in 30 seconds of review.
• Dependency graphs need to be explicit. "Run in parallel where possible" only works if the planner is forced to declare what depends on what.
• The model-tier assignment works best when the planner has a short rubric in its system prompt for which tier to pick. Letting it freelance ends up over-using the flagship.
• Notion as the substrate means non-technical operators can drive it. That was the unlock for me.

Caveats

• Not a fit if you don't already live in Notion.
• Subtasks that need shared state mid-run (long handoffs, iterative refinement between two agents) are weaker - the strength is parallel fan-out of independent work.
• Rate limits matter once you start fanning out 10+ Haiku tasks at once.

Stack

Notion as the board + database, Claude (Opus / Sonnet / Haiku) for planning and execution, a small orchestrator service that watches the Notion task DB and dispatches.

Repo

https://github.com/ratamaha-git/agency-os

Happy to answer questions on the planner prompt, the dependency-graph schema, or the model-tier rubric.

What if your Notion board was the thing that actually dispatched work to agents, not just tracked it?

That is what agency-os does. It is a Claude Code plugin (also works with Cursor, Cline, Continue, and any MCP-capable agent) that turns Notion into an orchestration layer: a place where you plan with an agent, approve a task tree, and then agents pick up rows marked for execution, complete them in dependency order, and write result links back to the board.

The loop in practice:

1. You describe an idea. The agent asks clarifying questions, breaks it into tasks and subtasks, sets dependencies on the Notion rows.
2. You approve. Nothing runs without explicit approval.
3. Tasks marked Exec=Agent get dispatched. Agents run in parallel where possible, sequentially where there are dependencies. Each one closes its row with a result link when done.

The Notion board is the source of truth throughout. There is no separate database, no config file to sync, no UI to keep open. The agent reads the board, writes to the board, and you see everything in one place.

Why Notion as the dispatch layer?

A few reasons this works better than a YAML task list or a chat thread:

• The board is human-readable and human-editable. You can add a task by typing in Notion, and the agent sees it on the next run.
• Dependencies are first-class. The agent resolves the DAG at dispatch time, stages tasks, and blocks a child if its parent did not close Done.
• Model routing is built in. Mechanical work (form fills, log-and-close tasks, directory submissions) runs on fast cheap models. Substantive drafting and reasoning goes to bigger ones. You configure which tier handles which kind of work at init time. On typical workloads this cuts token spend 5-10x versus routing everything through a flagship model.

The MCP angle

The whole thing runs through MCP. Notion connectivity is via the Notion MCP server. The skill spec itself (.claude/skills/agency-os/SKILL.md) is plain readable markdown that any MCP-capable harness can load. Cursor, Cline, and generic MCP agents all work; the README has harness-specific setup guides.

Honest dependency note

The planning and execution layer uses Claude via the Anthropic API. There is no local-model path yet. The skill spec is model-agnostic in principle - it is just instructions - but the current integrations assume an Anthropic-compatible endpoint. If you are running fully local, this is not ready for you yet. Flagging it rather than burying it.

MIT licensed. No telemetry, no call-home. Your Notion data stays in your workspace under your own API token.

Happy to answer questions about the architecture, the dependency resolution, or the model routing config.