Building Reliable Workflows with Generative AI Models

Last month I needed to turn a stack of PDF invoices into a quick summary for a client meeting. I had the files, I had a deadline, and I wanted to avoid copying numbers by hand. I decided to see if I could glue a generative AI model to a simple automation that would extract the totals, dates, and vendor names, then spit out a CSV. What followed was a mix of wins, head‑scratches, and a few hard lessons about how these models behave when you ask them to work repeatedly.

Why does the output drift when you scale prompts?

When you first test a prompt in the playground, the model often returns exactly what you expect. Run the same prompt fifty times in a loop and you’ll start seeing variations: extra commas, missing fields, or even a completely different format. This drift happens because the model samples from a probability distribution each time, and tiny changes in the input (like whitespace or a stray newline) can shift the probability mass enough to alter the answer. If you treat the model as a deterministic function, you’ll get bitten when you move from a single test to a batch job.

To curb drift, I started adding a strict output format instruction and a validation step. I asked the model to return JSON only, and I wrapped the call in a tiny script that checks for required keys. If the JSON fails to parse, the script retries with a slightly tweaked prompt that reminds the model to stay in bounds. This loop cut the failure rate from about thirty percent to under five percent in my tests.

What most guides get wrong about chaining models

Many tutorials show you how to call one model, then feed its output straight into another model as if the data were clean. In reality, the first model’s output often contains markdown fences, explanatory text, or stray characters that break the second model’s parser. I’ve seen guides that suggest “just trust the model to output clean JSON” and then wonder why the pipeline crashes after a few runs.

What works better is to insert a deterministic cleaning step between models. A simple regex that strips anything outside the outermost curly braces, or a lightweight JSON‑repair library, can save you hours of headache. Treat the AI as a noisy sensor, not a reliable data source, and add a sanitizer before you hand off to the next stage.

A concrete example: turning PDFs into invoice summaries with GPT-4o and Make.com

Here’s the exact flow I built:

• Step 1: Use Make.com’s PDF extractor module to pull raw text from each invoice.
• Step 2: Pass that text to GPT-4o with the following prompt (bolded on first mention): GPT-4o receives the system message “You are an invoice parser. Return ONLY a JSON object with fields: invoice_number (string), date (ISO 8601), vendor (string), total_amount (number). Do not add any extra text.” and the user message containing the extracted text.
• Step 3: Run a JavaScript step that tries to JSON.parse the output. If it fails, the step sends a follow‑up prompt: “Your previous answer was not valid JSON. Please output only the JSON object as described earlier.” and retries up to two times.
• Step 4: If parsing succeeds, push the object to a Google Sheets row.
• Step 5: If all retries fail, log the raw output to an error queue for manual review.

I kept the temperature at 0.2 to reduce randomness, and I set max_tokens to 250—more than enough for the short JSON. The whole scenario runs in under two seconds per invoice on Make.com’s free tier, which gave me 1 000 operations a month. For my volume of about 150 invoices a month, the free plan was enough.

Love: The ability to see the raw model output in Make.com’s log panel saved me when I first spotted that the model was wrapping JSON in triple backticks. Being able to click a log entry and see exactly what the model returned cut my debugging time from hours to minutes.

Gripe: The PDF extractor sometimes garbles numbers when the invoice uses a fancy font, turning “1 234,56” into “123456”. I had to add a preprocessing step that re‑inserts commas based on decimal position—a fiddly fix that felt like duct‑taping a leaky hose.

How to debug when the JSON breaks

When the parser throws an error, the first thing I do is look at the raw model response in the logs. Nine times out of ten the issue is one of three things:

• The model added a preamble like “Here is the JSON you requested:” before the braces.
• The model used single quotes instead of double quotes for keys or strings.
• The model truncated the output because max_tokens was too low, leaving a dangling comma or missing closing brace.

I fixed each case with a targeted tweak:

• For preambles, I added the phrase “Do not include any introductory text. Return ONLY the JSON.” to the system prompt.
• For quote problems, I ran a quick regex that replaces single quotes with double quotes, but only outside of escaped sequences.
• For truncation, I increased max_tokens by 50 and added a fallback that asks the model to continue if the JSON does not parse.

Having a small retry loop that logs each attempt makes it easy to see which fix helped. If after three attempts the JSON still fails, I know the prompt itself is ambiguous and I rewrite it with more concrete examples.

Price check: is the paid tier worth it?

Make.com’s free tier gives you 1 000 operations a month, which covered my invoice workflow with room to spare. The next paid tier starts at $29/mo and bumps you to 10 000 operations. I think $29/mo is fair if you’re processing a few thousand items a month and need the reliability of higher concurrency. The $199/mo tier feels overpriced for a solo operator unless you’re hitting hundreds of thousands of runs—something I haven’t seen in my own use cases.

For more on this exact angle, AI meeting tools coverage.

If you’d rather skip the build and deploy a working version in an afternoon, we’ve packaged this workflow as a blueprint at deepusecase.com/vault.