Building Reliable Automations with Generative AI Models

The Core Problem: Unstructured Text is a Nightmare

The biggest lie about generative AI models is that they’re plug-and-play for automation. They aren’t. They are incredible at understanding and generating human-like text, but that’s a liability in an automated workflow. Automation runs on structured data—JSON, specific numbers, boolean flags. It doesn’t run on pleasantries.

Imagine you want to automate lead processing from your contact form. An inquiry comes in: “Hi, this is Bob from Acme Corp. We’re interested in your services and have a budget of around $15,000. Can you email me at bob@acme.com? Thanks.” You send this to a generic GPT-4 prompt. You might get back: “The user’s name is Bob, he works at Acme Corp, and his email is bob@acme.com. His budget is approximately $15,000.”

What can you do with that paragraph? Nothing. You can’t pipe it into your CRM. You can’t use it to route Bob to the right sales rep. You’re stuck writing fragile regular expressions to find the email address, hoping nobody ever writes “my email is” in a weird way. This is the fast path to a brittle system that breaks if someone uses an emoji. It’s a maintenance disaster waiting to happen.

What Most Guides Get Wrong About Prompting for JSON

The standard advice you’ll find on a dozen AI blogs is just lazy. They tell you to add a simple instruction to your prompt: “Please respond only in JSON format.”

This is actively harmful advice for anyone building a system that needs to run without a human babysitting it.

Why? Because it’s a suggestion, not a command. The model will often try to be helpful, breaking the very format you requested. You’ll get responses wrapped in conversational fluff like, “Sure, here is the JSON you requested:” followed by a code block. Or it will add helpful comments inside the JSON, which will break your parser. Or, my personal favorite, it will hallucinate a field that wasn’t in your original spec or miss a comma. Each of these failures requires custom error handling and makes your automation unreliable.

Relying on a simple text instruction to get structured data is like asking a toddler to please color inside the lines. It might work a few times, but you’re going to get crayon on the wall. For any real business process, that’s not good enough.

The Production-Grade Fix: Function Calling and Tool Use

The correct way to get reliable, structured output from modern generative AI models is to use their built-in tool-use or function-calling capabilities. This feature is available in APIs from OpenAI, Anthropic (Claude), and Google (Gemini). It fundamentally changes the interaction from a conversation to a structured command.

Instead of just giving the model a text prompt, you also provide a strict schema of the data you want back. You’re essentially telling the model, “Analyze this input, and if you find the relevant information, your *only* valid way to respond is by filling out this specific form.” The model is then forced to structure its output to match your schema perfectly. No extra chatter. No missed fields. Just clean, predictable JSON.

Here’s a conceptual example of what you’d send to the OpenAI API to extract details from our example lead email. You define a “function” or “tool” with a name, a description, and a list of parameters with their types.

{  "model": "gpt-4o",  "messages": [    {      "role": "system",      "content": "You are a lead processing assistant. Extract information from the user's message."    },    {      "role": "user",      "content": "Hi, this is Bob from Acme Corp. We're interested in your services and have a budget of around $15,000. Can you email me at bob@acme.com? Thanks."    }  ],  "tools": [    {      "type": "function",      "function": {        "name": "save_lead_details",        "description": "Saves the extracted details of a potential lead.",        "parameters": {          "type": "object",          "properties": {            "contact_name": {              "type": "string",              "description": "The full name of the contact person."            },            "company_name": {              "type": "string",              "description": "The name of the company the lead works for."            },            "email_address": {              "type": "string",              "description": "The contact's email address."            },            "budget": {              "type": "integer",              "description": "The estimated project budget in USD."            }          },          "required": ["contact_name", "company_name", "email_address"]        }      }    }  ],  "tool_choice": {"type": "function", "function": {"name": "save_lead_details"}}} 

By setting `tool_choice` to force the function, you remove all ambiguity. The API’s response will contain a perfectly formed JSON object in the `arguments` field, ready to be parsed and used. The moment I switched to this method for my own lead enrichment agent, the error rate from malformed AI outputs dropped from around 15% to less than 1%. It just works.

Is the OpenAI Function Calling API Overpriced?

When you start making hundreds or thousands of API calls a day, cost becomes a real factor. Is forcing a structured response with a tool-use model like GPT-4o more expensive than just trying to parse the output of a cheaper model?

Let’s look at the numbers. As of early 2026, GPT-4o costs about $5 per million input tokens and $15 per million output tokens. A typical lead processing request like our example might be around 500 tokens total. You could process 2,000 such leads for a dollar. Honestly, that’s a bargain. The engineering and maintenance time you save by not having to write and debug fragile parsers pays for the API calls ten times over.

Some people try to get around this by using a cheaper model like GPT-3.5-Turbo. While it also supports function calling, my gripe is that it’s just not as reliable. It’s more likely to fail to call the function on ambiguous inputs or to hallucinate a value. For production workflows, the slight cost savings isn’t worth the increase in headaches. For the reliability it provides, the cost of a premium model is completely justified. Don’t cheap out on the core of your automation.

How to Debug When This Breaks

Even with function calling, your system can fail. The model isn’t magic; it’s a complex system with failure points. When your automation grinds to a halt, here’s a checklist for figuring out what went wrong.

• Check the Input First. The most common failure is garbage in, garbage out. Was the input email a blank string? Was it formatted weirdly or full of irrelevant junk? Log every raw input that causes a failure. You’ll often find the problem isn’t the model, but the data you’re feeding it.
• Did the Model Refuse to Call the Function? Sometimes, the model will correctly determine that the required information isn’t present in the input. If your schema requires a `budget` but the email doesn’t mention one, the model might not call the function at all. This is often the *correct* behavior. Your code needs to handle the case where the function call is absent from the response.
• Is Your Schema Too Complex? Don’t ask the model to extract 30 different fields from a single paragraph. Break down complex tasks. Use one model call to determine the user’s intent, and then a second, more specific call to extract the details relevant to that intent. Simpler schemas lead to more reliable results.
• Add Examples to Your Prompt. If the model is consistently misunderstanding a specific type of input, add a few examples directly into your prompt. This is called few-shot prompting. Show it an example of the input text and the corresponding correct JSON output you expect. This can significantly improve accuracy for tricky edge cases.

My biggest personal gripe is with orchestrators that don’t handle API timeouts well. I’ve used no-code platforms like Make where a step can just hang indefinitely if the AI model is slow to respond. It’s infuriating. Ensure your system has proper timeout settings and a retry mechanism for transient network errors. Without it, your entire pipeline is fragile.

Tying It All Together: A Simple Lead Qualification Agent

Let’s build a mental model of a complete, simple AI agent using this technique. This is a basic operator playbook for automating lead qualification.

1. The Trigger: The workflow starts when a new form is submitted on your website. Tools like Webflow or Carrd can send this data to a webhook.
2. The Schema Definition: You define the exact data structure you need. Let’s say it’s `{“lead_name”: “string”, “company_size”: “enum(1-10, 11-50, 50+)”, “is_qualified”: “boolean”}`. You’ve decided a lead is qualified if their company size is over 50 employees.
3. The System Prompt: You craft a clear, concise prompt that defines the AI’s role and goal. “You are an expert SDR. Your job is to analyze the user’s message and determine if they are a qualified lead based on their company size. A company with over 50 employees is qualified. Use the `qualify_lead` tool to save your analysis.”
4. The API Call: Your automation platform (like Pipedream, which is great for this kind of custom code step) receives the webhook, combines the prompt and the schema, and makes a tool-use API call to a generative AI model like Claude 3 Sonnet.
5. The Structured Response: The API returns a clean JSON object: `{“lead_name”: “Bob”, “company_size”: “50+”, “is_qualified”: true}`. There’s no extra text to parse.
6. The Action: Now your workflow can use this structured data. If `is_qualified` is true, it adds the lead to your CRM with a “Hot” tag and notifies your sales team on Slack. If false, it sends a polite automated rejection email.

This is a real, working automation. It’s reliable because each step operates on predictable, structured data. This is the difference between a cool demo and a business asset.

For more on this exact angle, deeper coverage of AI agent platforms.

You can build this entire pipeline from the steps above using an automation platform and an AI model’s API. It’ll take some configuration and testing to get the details right. Or, if you want to skip the setup and debugging, we’ve packaged this exact lead qualification system as a deployable AI automation blueprint. You can find it at deepusecase.com/vault.