You ask Gemini to adapt one Airtable draft for Instagram, Pinterest, and Threads. Most runs look fine. Then a platform gets this as its caption:
Sure! Here is an engaging Instagram caption for your brand:
Or a blank string. Or a plausible sentence with an invented discount. A scheduled workflow can publish all three without anyone seeing the problem first.
The fix is a small contract between the AI step and the publishing step: request structured fields, parse them, then check them before posting. This is a separate issue from duplicate prevention; each platform can publish exactly once and still publish bad copy.
Start with a narrow output shape
For one destination, request a JSON object like this:
{
"caption": "A complete, ready-to-publish caption",
"cta": "A call to action supported by the source draft",
"needs_review": false,
"review_reason": ""
}
Make caption, cta, needs_review, and review_reason required in the schema. Use a separate request or schema per platform if their fields differ. For Pinterest, you might use title and description; for Instagram, caption may be enough. Avoid one giant object with many optional fields that every later module must guess how to use.
Google's Gemini API supports structured output with a JSON schema. The exact setting depends on the API or Make module you use. If that module exposes a response format or schema control, use it. If it does not, a prompt asking for JSON is only an instruction to the model, not a format guarantee; parse and reject bad results before the publish module. Google documents a supported subset of JSON Schema, so keep the schema simple and test it against the model you select.
Tell the model what it may use
An example instruction for the Instagram step:
You write an Instagram caption from the source fields below.
Return only the fields in the configured JSON schema.
Use only facts, prices, offers, links, and product claims present in the source.
Do not invent a discount, testimonial, deadline, or result.
If the source lacks a fact needed for a safe caption, set needs_review to true,
explain the missing fact in review_reason, and keep the caption empty.
Do not add an introduction such as "Here is your caption".
Title: [map Airtable Title]
Source draft: [map Airtable Caption]
Approved CTA: [map Airtable CTA]
Map fields with Make's mapping controls; do not paste actual account keys or private customer details into a reusable prompt. An empty caption is acceptable only when the scenario routes it to review instead of publishing.
Put checks between Gemini and the social module
In Make, parse the Gemini response as JSON, or use the module's structured fields when it returns them directly. Define the expected Make data structure so downstream mapping is explicit. Then use a filter before the publishing module:
- needs_review must be false.
- caption must be nonempty after trimming whitespace.
- The text must fit the destination's current limits, which you should verify in that destination's own module or documentation.
- Required source facts or approved link must still be present if your workflow depends on them.
Route anything else to a review queue in Airtable. Save the generated text and a reason such as empty caption, invalid JSON, over length, or unverified claim. Do not use a Skip handler as your sole quality control: dropping a failed bundle does not explain what needs editing.
For a higher-risk claim, add human approval even when the JSON parses. A schema can constrain shape; it cannot prove that a discount exists, a health claim is accurate, or a link points to the intended product. This is a business rule, not a parsing rule.
Test deliberately bad inputs
Create three test Airtable records before scheduling:
| Source draft | Expected behavior |
|---|---|
| Clear product facts and an approved CTA | Valid caption reaches the test publishing step |
| Missing offer details but asks for a discount | needs_review or a failed business-rule check; no publish |
| Empty draft or malformed AI response | Review queue receives a reason; no publish |
Inspect the actual Make bundles after Run once. Check the parsed field mapped into the social module, not just the AI module's raw response. The best evidence is a test post on a controlled account and a corresponding Airtable result.
The goal is modest but important: an AI caption should have to pass a visible gate before the social API sees it. That gate does not make the writing perfect. It makes broken or unsupported output easier to catch and fix.
I also made Small Budget, Big Results: SMM Automation Guide, a $15 guide with a 15-page PDF, an edited Make blueprint, and a setup checklist. It covers the broader Airtable → Make → Gemini workflow. The blueprint is a setup-required example: connect your own accounts, map fields, add your validation and retry rules, and test before scheduling.
Top comments (0)