Back to blog

I Built an Instagram Workflow with OpenAI Dots — and Review Happens in Slack

Still-image drafts, exact-artifact approval, deliberate public delivery, and a verified return path.

Chris Eberl

Chris Eberl

Founder • Engineering Leader, GenAI, Data, ML

AI EngineeringOct 6, 20267 min read
I Built an Instagram Workflow with OpenAI Dots — and Review Happens in Slack

I wanted social media to become a repeatable workflow, not another place to remember unfinished work. The useful question was not whether an assistant could make an image. It was whether a draft could arrive with its complete caption, receive a specific approval, reach Instagram, and return a verified link without losing the review boundary.

The setup produced two still-image test posts, with their live links checked afterward. The second test exercised the complete Slack approval-to-publication path. The recurring production schedule is configured, but its first run has not happened yet.

A Dot coordinates; the services keep distinct jobs

OpenAI dots provide an ongoing agent rather than a disposable conversation. Here, the responsibility is narrow: prepare one still-image draft, collect owner review, publish only the exact approved artifact, and bring back confirmation. This is my selected approval contract, not a claim that all Dots are inherently draft-only.

Cropped coral-orange rounded Dot avatar with black headphones, small dark oval eyes and a looping dark facial accent.
The Dot I configured for this workflow.
ServiceJob in this setupBoundary
SlackReview image and captionOwner approval in the draft thread
WindsorInstagram publishing and insightsWrite actions manually enabled
CreatifyPublic JPEG delivery; future video generationApproved media may be publicly accessible
Google DriveDated image and caption archivePrivate; local copies retained
Meta AdsRead-only insightsNo paid-ad changes
StripeOptional safely aggregated contextOld catalog is not current pricing evidence

Separate jobs. Separate permissions.

  1. OpenAI Dot

    Draft + coordinate

  2. Slack

    Human review

  3. Creatify

    Public media delivery

  4. Windsor

    Publish + verify

Drive: private archive · Meta Ads: read-only insights · Stripe: optional aggregate context.
Coordination, review, delivery and publishing are separate responsibilities.

Connecting a service is not the same as proving its useful action works. App connections and contact channels are distinct. Slack is the communication surface here; adding a Slack contact alone does not establish monitoring or authorize publication. Windsor was on an unpaid trial in the setup record, not a confirmed unlimited or permanent free tier.

The draft clock is not publishing permission

The saved recurring task is Monday and Thursday at 8am in America/Los_Angeles, with daylight-saving changes handled by that timezone. Each run produces one still-image draft and sends it when ready. Eight o’clock is the generation start, not a promised publication time. A person may review later, request changes, or decide not to publish.

As of the setup record on October 7 UTC, the first recurring run was scheduled for Monday, October 12. A separate already-approved one-time post was scheduled for October 8; it was not another completed test. Keeping tested actions and future events separate prevents a configured schedule from quietly becoming an invented track record.

The tasks and memory guide is useful here: specify a saved schedule, timezone, notification rules and destination, then obtain confirmation. Assigned work needs its relevant context. A conversational intention to repeat something is not the same as a confirmed recurring task.

Slack review needs an artifact-sized contract

Each draft arrives as a fresh top-level post in a private Slack channel, with the actual image and complete caption together. The captions are German in this setup. The owner approves in that draft’s thread, including from a phone. Approval authorizes that exact image and caption, not an unspecified future version or a general right to publish.

If the owner asks for a revision, the revised image and caption must be shown again for approval. The same thread receives the verified live link afterward. That gives the review a return path: readers can see what they approved and what was reported live without hunting through unrelated messages.

Approve the artifact, not the agent

  1. Image + caption

    One exact version

  2. Slack thread

    Owner reviews

  3. Scoped approval

    Upload + publish

  4. Live confirmation

    Same thread

Revision → show the updated image + caption → renewed owner approval.
A changed image or caption returns to review before any new publishing action.

The controls guide supports making scope and permissions explicit. Stopping delegated work and cancelling its schedule are separate decisions. The practical boundary here is consequential action: the Dot can prepare independently, but public delivery and publication wait for owner approval of the exact artifact.

Private archive, deliberately public delivery

The working still-image preset is JPEG, 1080×1350, sRGB, under 8MB. That is this workflow’s preset, not a universal Instagram format. Windsor’s single-image write action requires a publicly accessible JPEG, at most 8MB, with an aspect ratio between 4:5 and 1.91:1.

The private Drive archive stores the image and exact caption in a dated folder, with local copies retained. Publication follows a different path: Windsor publishes, and Instagram fetches the approved JPEG through Creatify’s publicly accessible delivery URL. Per-post owner approval covers that delivery upload as well as publishing. The disclosure happens before a feed post is necessarily live.

Private storage ≠ private delivery

  1. Private archive

    Drive + local copies

  2. Owner approval

    Disclosure boundary

  3. Public JPEG

    Creatify delivery

  4. Instagram

    Windsor publishes

The archive remains private. The approved delivery copy becomes publicly accessible for Instagram to fetch.
The private archive is not the media fetch endpoint. Approval includes creating the public delivery copy.

The delivery route worked in my setup; it is separate from Creatify’s asset-editing workflow. A private Drive archive does not make the publishing path private: the approved delivery copy must be reachable by Instagram.

A working route beats theoretical access

The initial browser publishing route failed with a generic cross-posting metadata error. The Windsor API route with public media delivery worked in the setup tests. I do not have a verified root cause for the browser error, and inventing one would not improve the lesson: choose the demonstrated publishing route, then test the whole chain rather than treating access as a working integration.

The Windsor Instagram integration reference provides context for that route. No custom AWS deployment or publishing script was deployed. More infrastructure would not have fixed the central problem of knowing what was approved and whether it actually became live.

An accepted API request is not proof of publication. If the result is ambiguous, inspect publishing status and Instagram before retrying. Otherwise, a slow response can turn into a duplicate post. My reader recommendation is to keep a stable draft identifier, exact approved version, source notes and publication confirmation; those provenance details are a proposed improvement, not something the setup record proves was already implemented.

A reader adaptation prompt

This is an example to adapt, not an instruction activating automation. Confirm the available actions, permissions and destination before saving any task.

Example approval contract
1Prepare ONE still-image draft per run.2Use my confirmed timezone and schedule.3Confirm the saved task and next run.4 5Show the actual image and full caption6together in a fresh review post.7Wait for my approval in that thread.8 9Approval covers ONLY that exact version,10its public delivery upload and publication.11Show revisions again for renewed approval.12Never treat silence as consent.13 14Keep the archive private.15Explain which delivery copy becomes public.16Verify source freshness before using claims.17 18If publication is ambiguous, inspect status19and Instagram before attempting a retry.20Return the verified live link in the thread.21Flag blockers and unknowns, not guesses.

Tested stills, planned Reels

Tested or configuredPlanned, not completed
Two still posts reported live and verifiedReel generation and publication
Slack approval-to-publication path testedApprove exact script before generation
Twice-weekly still drafting configured; first run pendingReview generated video before publishing
Public MP4 delivery proven in setup recordNo recurring video schedule agreed

Creatify is the intended video-generation service. No Reel has been generated or published in this workflow. Delivering a public MP4 proves a media-delivery step, not a completed Reel workflow. Video needs two review gates: the exact script before generation, and the generated video before publication.

Fresh sources and bounded next steps

Content alternates adult lifestyle scenes and graphic-led designs. German captions still need factual review: no real customer identities, fake testimonials, or unverified refund, price or guarantee claims. An old product catalog cannot establish today’s pricing. Optional Stripe context should remain safely aggregated and relevant, not a reason to expose customer details.

The next useful step is observing the first recurring draft. Check that the complete artifact arrives, revisions return to review, and confirmation follows publication. The lesson is practical: automate preparation, make disclosure explicit, and attach publishing permission to the exact thing a human reviewed.

Read next

Newsletter

New posts, straight from Chris

A short note from me whenever a new article goes live — product engineering, AI workflows, IoT, indie apps, and engineering leadership. No spam, unsubscribe anytime.

By subscribing, you agree to our Privacy Policy. We do not share your email.