Struggling to automate workflows with large language models like Claude? Learn why simple scripts fail against non-deterministic APIs and discover three practical, real-world solutions to build robust AI-driven automations that actually work.

Automating Claude: Why Your Genius Link-Building Script is Failing and How to Fix It

I got a Slack message at 10 PM on a Tuesday. It was from one of my brightest junior engineers. The message was just a link to a monitoring dashboard, drenched in red. “The outreach automation script is… over-enthusiastic,” he wrote. Turns out his ‘genius’ script to automate link-building outreach, which used the Claude API to find prospects and write emails, had decided a C-level executive at one of our existing enterprise clients was a “prime target for a guest post about Kubernetes.” The script had hammered their contact-us form 50 times in 3 minutes with a slightly different, nonsensical email each time. We spent the next hour doing damage control. This, right here, is the story of everyone’s first attempt at serious AI automation. You have a powerful tool, a clever idea, and you end up with a high-speed, unpredictable mess.

The Root Cause: You’re Treating a Poet Like a Calculator

The core problem I see over and over is a fundamental misunderstanding of the tool. We, as engineers, are used to deterministic APIs. You send a payload to the Stripe API, you get a predictable JSON response back. You send `{“amount”: 1000}`, you get `{“status”: “succeeded”}`. Do it a million times, you get the same structure back a million times.

LLM APIs like Claude are not like that. You’re not interacting with a predictable logic gate; you’re interacting with a highly complex pattern-matching engine. It’s non-deterministic by nature. The same prompt can yield slightly different results depending on factors you don’t even control. Your script fails because it expects a perfectly formatted, predictable string or JSON object every single time, but what it gets is a creative, sometimes flawed, and structurally inconsistent response. You can’t just pipe the output of an LLM call into another command and pray. You need a new playbook.

The Solutions: From Duct Tape to a New Engine

Look, I get the appeal. The idea of an AI handling a tedious task like finding blogs and drafting outreach is a dream. But to make it a reality, you need to build a resilient system around the AI, not just a one-line cURL command. Here are three ways to approach this, from the quick-and-dirty to the architecturally sound.

1. The Quick Fix: The ‘Grease Monkey’ Shell Script

This is the “I need this working by tomorrow” approach. We’re not rebuilding the engine, we’re just adding better guards and checks to our existing shell script. It’s hacky, but it’s a massive improvement over a naive one-shot script. The goal is to enforce structure and handle failures gracefully.

First, we force the AI to respond in JSON. This is the single most important thing you can do. Modify your prompt to be explicit.

# Part of your prompt given to Claude
...
Always respond with ONLY a valid JSON object in the following format. Do not include any other text or explanation.
{
  "contactName": "string or null",
  "contactEmail": "string or null",
  "suggestedSubject": "string",
  "emailBody": "string"
}

Next, we use a tool like jq to validate the output before we do anything with it. We wrap the API call in a loop to handle retries if the output is garbage or the API call fails.

#!/bin/bash

# A more robust shell script
MAX_RETRIES=3
RETRY_COUNT=0
TARGET_URL="https://some-target-blog.com/about-us"

while [ $RETRY_COUNT -lt $MAX_RETRIES ]; do
  # Assume 'claude_api_call' is a function that makes the API call and returns the raw text
  RESPONSE=$(claude_api_call --prompt "Analyze $TARGET_URL and return contact info as JSON...")

  # Check if the response is valid JSON and has the key we need
  EMAIL=$(echo "$RESPONSE" | jq -r '.contactEmail')

  if [[ "$EMAIL" != "null" && -n "$EMAIL" ]]; then
    echo "Successfully found email: $EMAIL"
    # ... proceed to send email or save to DB ...
    exit 0
  else
    echo "Attempt $((RETRY_COUNT+1)) failed. Invalid or null email. Retrying..."
    RETRY_COUNT=$((RETRY_COUNT+1))
    sleep 5
  fi
done

echo "Failed to get a valid response after $MAX_RETRIES attempts."
exit 1

Pro Tip: This is still fragile. If Claude decides to add a friendly “Here is the JSON you requested:” preamble before the opening brace {, your jq command will fail. It’s better than nothing, but be aware of its limitations.

2. The Permanent Fix: The ‘Architect’s’ Blueprint

This is how we’d do it for a real, production system. We stop thinking in terms of a single script and start thinking in terms of a multi-step, managed workflow. My tool of choice for this is often AWS Step Functions, but you can achieve the same result with a well-structured Python application or another workflow orchestrator like Airflow.

The idea is to break the process into distinct, manageable stages, with proper error handling and retry logic for each one.

• Step 1: Ingest URL: A Lambda function is triggered with a URL to process.
• Step 2: Generate Prompt: A dedicated function builds the precise, structured prompt.
• Step 3: Call Claude API: A function whose only job is to call the Claude API and handle API-level errors (like 429 Too Many Requests, 503 Service Unavailable). It retries with exponential backoff.
• Step 4: Validate & Parse: This is the crucial step. A different function takes the raw text output from Claude. It uses regex and JSON parsing libraries to find and validate the JSON block. If it fails, it can send the job to a failure queue or trigger an alert. It doesn’t just crash.
• Step 5: Take Action: Only after the data is validated does another function take the action, like adding the data to our `prod-db-01` or drafting an email for human review.

This decoupled approach means a failure in the unpredictable AI step doesn’t bring down the whole system. You can inspect failures, retry specific steps, and you have a clear, auditable trail of what happened. It’s more work to set up, but it’s the difference between a toy project and a production service.

3. The ‘Nuclear’ Option: Use a Wrench, Not a Sledgehammer

Sometimes, the problem is that we’re so enamored with the new AI hammer that we treat every problem like a nail. My junior engineer wanted Claude to do everything: scrape the site, identify the best person, find their email, and write the copy. That’s asking way too much from a single, non-deterministic tool.

The “nuclear” option is to radically simplify the AI’s job. Use deterministic tools for deterministic tasks.

Instead of the original plan, a better workflow is:

1. Scrape Site Content: Use a standard, reliable Python library like BeautifulSoup or Scrapy to pull all the text and email addresses from the target page. This is 100% reliable.
2. Filter and Select: Use simple logic to filter for common contact email patterns (`contact@`, `press@`, etc.) or identify names near job titles.
3. Use AI for ONE Small Thing: Now, take the clean text content from the “About Us” page and feed *only that* to Claude with a very specific prompt: “Based on the following text, summarize the blog’s main topic in one sentence.”
4. Assemble with a Template: Use a simple templating engine (like Jinja2) to assemble the final email. `Hi [Contact Name], I saw your post on [AI-Generated Summary]…`

In this model, the AI is no longer responsible for mission-critical structure and data extraction. It’s being used for what it’s good at: summarizing and rephrasing unstructured text. The unreliable part of your workflow is now small, contained, and its failure doesn’t break the entire chain.

Comparison of Approaches

There’s no magic bullet for automating tasks with LLMs. The key is to treat them as powerful but sometimes erratic junior partners, not as infallible APIs. Build scaffolding, add guardrails, and always, always have a plan for when the output looks nothing like you expected. Now if you’ll excuse me, I need to go add a new alert for “anomalous email volume to key accounts.”

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions