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.

| Service | Job in this setup | Boundary |
|---|---|---|
| Slack | Review image and caption | Owner approval in the draft thread |
| Windsor | Instagram publishing and insights | Write actions manually enabled |
| Creatify | Public JPEG delivery; future video generation | Approved media may be publicly accessible |
| Google Drive | Dated image and caption archive | Private; local copies retained |
| Meta Ads | Read-only insights | No paid-ad changes |
| Stripe | Optional safely aggregated context | Old catalog is not current pricing evidence |
Separate jobs. Separate permissions.
OpenAI Dot
Draft + coordinate
Slack
Human review
Creatify
Public media delivery
Windsor
Publish + verify
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
Image + caption
One exact version
Slack thread
Owner reviews
Scoped approval
Upload + publish
Live confirmation
Same thread
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
Private archive
Drive + local copies
Owner approval
Disclosure boundary
Public JPEG
Creatify delivery
Instagram
Windsor publishes
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.
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 configured | Planned, not completed |
|---|---|
| Two still posts reported live and verified | Reel generation and publication |
| Slack approval-to-publication path tested | Approve exact script before generation |
| Twice-weekly still drafting configured; first run pending | Review generated video before publishing |
| Public MP4 delivery proven in setup record | No 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.
Further reading — OpenAI
Further reading — publishing and assets
