DEV Community: Agrici Daniel

The Open-Source AI Marketing OS I Am Building in Public

Agrici Daniel — Fri, 31 Jul 2026 06:00:00 +0000

The Open-Source AI Marketing OS I Am Building in Public

My AI marketing stack is not one giant agent.

It is a set of small systems with clear jobs. Context retrieves evidence. SEO and ads skills perform bounded analysis. Content skills turn research into structured assets. Media tools adapt owned material. Postiz receives approved platform-native drafts. A human stops execution when the claim, destination, or output is not ready.

The shared layer is evidence.

This is the install order and operating model I use to keep the stack inspectable.

Start with the bottleneck, not the tool count

An operating system does not become useful because it contains more repositories.

It becomes useful when one component removes a measurable bottleneck without hiding the source, the failure boundary, or the human decision.

Pick one job first:

retrieve the right company context
audit one owned page
structure one ad review
turn one research packet into a brief
cut one owned video into a Short
create one approved social draft

Run that job end to end. Measure the review load. Add the next component only when the workflow needs it.

Layer 1: source-cited context

Claude Obsidian is the context layer.

Its job is not to store the largest possible pile of notes. Its job is to retrieve the relevant source when work begins, show the date and status of that source, and produce a bounded next action.

A working context loop looks like this:

question
  -> retrieve candidate pages
  -> inspect source and date
  -> answer with a bounded action
  -> store a reviewed correction
  -> retrieve that correction in a later task

The last step matters. Persistent files are not the same as learning. A correction becomes operational memory only when a later task can retrieve it in the right scope.

Layer 2: reusable marketing skills

The skill layer splits marketing work into inspectable jobs.

Claude SEO routes SEO audits, content checks, technical tasks, and structured research.
Codex SEO adapts the same builder-led SEO approach for a Codex workflow.
Claude Ads separates paid-media review by platform, attribution, budget, creative, tracking, and validation.
Claude Blog separates research, briefs, drafting, fact checks, images, localization, and post-write quality control.

The repository name is not the proof. The useful proof is a bounded run with:

one defined input
a visible method
a reviewable output
a known failure boundary
a decision about what happens next

Stars can show attention. They cannot replace that test.

Layer 3: owned media production

The media layer should begin from an owned source asset.

Claude Shorts turns long-form footage into short-form production steps. Banana Claude covers image-generation workflows.

The source link stays attached to the derivative. That keeps the Short, visual, caption, and destination aligned with the same underlying claim.

For video, the output contract is explicit:

1080 by 1920
H.264 video
AAC audio
burned-in captions
no private paths or credentials on screen
one CTA

For deterministic diagrams and carousels, the text and measurements remain editable. Generated illustrations stay textless so claims are not baked into an image that cannot be corrected.

Layer 4: connected publishing tools

Postiz is the publishing layer in this setup.

It is self-hosted on Railway with Redis, Postgres, and Temporal behind the application. The current instance exposes a Public API and MCP endpoint. Seven social integrations are connected.

That is connection proof, not publication proof.

The publishing path stays staged:

local validation
  -> media upload
  -> representative provider draft
  -> rendered preview
  -> owner approval
  -> Week 1 schedule
  -> controlled public test
  -> Week 2 schedule

Pinterest is currently blocked because the connected integration returns no board. Its assets remain complete but unscheduled until Postiz returns a real board ID.

The approval layer wraps execution

Approval is not a fifth tool beside the stack. It is the boundary around every action that changes public state.

The reviewer checks:

whether the source supports the claim
whether mutable facts were refreshed
whether the copy is native to the platform
whether the media shows the same system described in the post
whether the destination exists and matches the CTA
whether the selected account and time are correct
whether a rollback path exists

The automation can prepare the decision. It does not inherit authority to publish every future derivative.

A practical install order

1. Install the context layer

Start with a small, source-cited vault. Put one recurring marketing decision inside it. Test whether the system can retrieve the right note, date, and next action.

2. Add one skill for one job

Choose the bottleneck you can measure. An owned-page SEO audit is a better first test than “automate SEO.” One ad-account review is a better first test than “run paid media.”

3. Define the output contract

Write down what the component must return. Include the source, status, priority, limitation, and human checkpoint.

4. Connect publishing last

Publishing multiplies mistakes. Connect it after the local output is stable, the media contract is validated, and the approval state is explicit.

5. Measure the quality cost

Track editing time, corrections, failures, and review burden beside reach or clicks. A system that creates more cleanup than useful work has not earned another layer.

What is public and what is still being connected

The seven AgriciDaniel repositories named above were public and reachable through the GitHub API on July 16, 2026. Their versions, install paths, licenses, and maintenance status must still be refreshed before a dated recommendation.

The Postiz deployment is connected and healthy. The first provider previews and controlled public tests are still required. The two-week social batch is built around that boundary.

I do not call the full stack autonomous. I call it inspectable.

That is the operating advantage: every component owns one job, every claim keeps its source, and every public action stops for approval.

Sources

Join the free AI Marketing Hub and start with the one marketing bottleneck you can measure.

Build a Source-Grounded Social Engine With a Human Approval Gate

Agrici Daniel — Fri, 24 Jul 2026 06:00:01 +0000

Build a Source-Grounded Social Engine With a Human Approval Gate

I connected seven channels to a self-hosted Postiz instance.

That was the easy part.

The difficult part is preventing a research note, an outdated number, or a generic draft from moving straight into a public calendar. A healthy API connection proves that Postiz can reach an account. It does not prove that the claim is current, the copy fits the platform, the media is correct, or the publication time is approved.

My workflow separates those decisions.

The system is:

Current research
An evidence ledger
Platform-native drafts
Human approval
A Postiz preview
Controlled scheduling
Measurement that changes the next batch

Nothing publishes automatically. The automation ends at a reviewable draft until a human approves the complete asset.

1. Start with a dated research record

A trend is a time-bound observation, not a promise that a post will perform.

For each topic, I keep:

the source URL
the retrieval date
what the source directly supports
what I infer from it
the confidence level
the date the claim must be checked again

Mutable repository counts, versions, product behavior, prices, and social metrics expire quickly. A draft can stay useful while the number inside it becomes wrong. The refresh date makes that visible before publication.

Qualitative discussions need another boundary. Three useful community threads can reveal language, objections, and workflow pain. They do not represent the entire market. I write “the discussions clustered around these jobs,” not “marketers want this.”

That distinction is small in the copy and important for trust.

2. Put every public claim in an evidence ledger

The evidence ledger is the handoff between research and production.

A minimal record looks like this:

{
  "claim_id": "postiz-seven-connections",
  "claim": "Seven social integrations are connected and healthy.",
  "source": "Postiz Public API integration list",
  "observed_at": "2026-07-16T14:00:00+03:00",
  "confidence": "high",
  "expires_at": "2026-07-19T14:00:00+03:00",
  "limitation": "No provider has completed a controlled public test."
}

The limitation is part of the record. Seven healthy connections do not mean seven proven publishing paths.

In my current setup, Pinterest is connected but Postiz returns no board. The ten Pin assets can be completed, reviewed, and stored. They cannot become schedules until the integration returns a real board ID.

3. Produce native assets from one evidence packet

The core idea can stay consistent. The delivery should change.

An X post needs a compact observation and one action. LinkedIn can explain the operating decision across a carousel. Mastodon needs enough context to stand alone. Pinterest needs a durable, keyword-forward title and a vertical visual. Dev.to should hold the full implementation, not a padded social caption.

The same paragraph pasted across seven networks is distribution, not adaptation.

I store each derivative as its own asset with:

a unique ID
the target integration
the scheduled local time and UTC offset
the copy path
the media paths
the provider settings
the destination
the source ledger
approval and Postiz state

This matters because approval of the topic is not approval of every derivative. One Pin may have a weak destination. One carousel may contain a stale figure. One Short may expose a private screen. Every public asset needs its own decision.

4. Make the human gate explicit

The reviewer approves the whole publication unit:

copy
media
claim source
account
destination
provider settings
time
rollback plan

The state machine is simple:

researched
  -> drafted
  -> media-ready
  -> approved
  -> postiz-draft
  -> scheduled
  -> published
  -> measured

An asset cannot skip from drafted to scheduled because a script can construct the payload.

Representative previews come first. I create one draft for each provider, inspect the rendered result inside Postiz, and correct the shared template. Only then does the batch move forward.

5. Keep the Postiz operator dry-run by default

The local operator uses the self-hosted Public API documented by Postiz. Media goes through POST /public/v1/upload. Posts go through POST /public/v1/posts. The API supports draft, schedule, and now post types.

The safe interface keeps network writes explicit:

python3 scripts/postizctl.py health --skip-custom
python3 scripts/postizctl.py integrations
python3 scripts/postizctl.py batch production/manifest/2026-07-20--2026-08-02.json

Those commands inspect or validate. They do not create anything.

A network write requires --send:

python3 scripts/postizctl.py batch \
  production/manifest/2026-07-20--2026-08-02.json \
  --asset W1-05-LI \
  --send

The operator hashes every media file before upload. If the exact file already has a valid Postiz receipt, the upload is reused. The receipt stores the media ID, public path, hash, and upload time. It never stores the API key.

6. Validate provider rules before the request

Each provider has a different contract.

In this self-hosted instance, the live non-Premium X schema returns a 200-character limit. LinkedIn image carousels need at least two images. Pinterest requires media and a board. Dev.to needs a title and accepts up to four tags in the current schema. YouTube needs one MP4 plus a title and visibility setting.

The manifest translates those differences into provider settings:

{
  "platform": "linkedin",
  "settings": {
    "__type": "linkedin",
    "post_as_images_carousel": true
  }
}

Local validation catches missing settings, wrong integration mappings, expired timestamps, missing media, character-limit failures, and duplicate asset IDs before the API sees the payload.

7. Roll out one provider at a time

The first real post on each platform is a controlled test.

After it publishes, I verify:

the public URL
copy formatting
media order and quality
captions and thumbnails for video
destination behavior
provider-specific settings

If X fails, the X rows stop. LinkedIn, Bluesky, Mastodon, Dev.to, and YouTube do not need to stop with it. Provider isolation keeps one integration problem from turning into a batch-wide incident.

Week 2 stays on hold for a provider until its Week 1 controlled post succeeds.

8. Measure quality cost, not only reach

The useful metrics depend on the job of the post.

For reach, I track impressions or views. For interest, I track qualified replies, saves, profile visits, and completion rate where the platform exposes them. For trust, I track clicks to the full guide, repository visits, and video watch depth. For conversion, I track attributable Free Hub visits and join starts.

I also track the cost of the system:

editing time
claim corrections
upload failures
provider failures
reply burden

A topic is not worth repeating when it creates more review and cleanup than useful action.

Current boundary

As of July 16, 2026, the app, Public API, MCP endpoint, and seven integrations are healthy. Pinterest scheduling remains blocked because no board is returned. No provider has completed a controlled Postiz publish test. The two-week batch is a reviewed production system, not proof of an autonomous publishing loop.

That is the point of the gate. It keeps the public claim equal to the system that exists today.

Sources

Join the free AI Marketing Hub and share the workflow you want to put behind a human approval gate.