Why We Chose Script Orchestration Over Agent Orchestration for Daily Automation

At Ledd Consulting, we run 25 microservices, 60+ systemd timers, and 7 AI agents in production. Every morning at 9 AM EST, a daily playbook fires: it drafts proposals for top job matches, checks marketplace activity, generates outreach emails, publishes an SEO blog post, and emails a summary of every action taken. The entire pipeline runs on a single Node.js script — deterministic control flow, with AI called surgically for content generation.

We made this choice deliberately. Here's the full decision record.

Context — The Decision We Faced

Our consulting operation needed a daily automation pipeline that would take real actions — draft proposals, publish blog posts, send emails, update CRM records. The comment at the top of our production playbook says it plainly:

/**
 * Autonomous Daily Playbook — Proactive Revenue & Growth Actions
 *
 * This is NOT a report generator. This script ACTS:
 * 1. Drafts proposals for top job matches
 * 2. Checks marketplace activity
 * 3. Generates cold outreach email from research intel
 * 4. Drafts a blog post for SEO
 * 5. Checks subscribers & generates promo if needed
 * 6. Emails a summary of all autonomous actions taken
 *
 * Timer: 9 AM EST (14:00 UTC) daily
 * Cost: $0 (uses claude CLI via subscription)
 */

Six steps, each involving real-world side effects — file writes, API calls, email sends, CMS publishes. The question: should we build this as an autonomous AI agent that decides what to do each morning, or as a deterministic script that calls AI only for content generation?

This matters because the default industry instinct in 2026 is "just give it to an agent." We had to resist that instinct and think clearly about what orchestration actually requires here.

Options Considered

Option A: Full Agent Orchestration (ReAct Loop)

We already run ReAct agents in production. The pattern is well-understood: the agent receives a goal ("execute the daily playbook"), reasons about what to do, selects tools, observes results, and iterates until complete.

Pros:

• Adaptive — handles unexpected situations gracefully
• Can reprioritize mid-run based on discoveries
• Feels elegant; single entry point

Cons:

• Every run is a black box — different execution path each time
• Token cost scales with reasoning steps (5–15 LLM calls just for planning, before any content generation)
• Failure modes are opaque: did it skip the blog post because it decided to, or because it hallucinated that it already published one?
• Debugging requires reading full conversation traces

Option B: Workflow Engine (Temporal, Prefect, Airflow)

A proper DAG-based workflow engine with retries, observability, and state management.

Pros:

• Industrial-grade retry and failure handling
• Built-in observability dashboards
• Well-understood by DevOps teams

Cons:

• Heavy dependency for a six-step pipeline
• Requires dedicated infrastructure (Temporal server, or managed Prefect/Airflow)
• Our entire VPS runs 25 services already — adding a workflow engine doubles operational surface area
• Overkill: our steps are sequential with simple dependencies

Option C: Deterministic Script + Targeted AI Calls

A plain Node.js script with explicit control flow. Each step runs in order. AI is invoked only where generation is needed — drafting proposal text, writing blog content, composing emails. The script handles all orchestration, file I/O, API calls, and error handling.

Pros:

• Every run follows the same path — fully auditable
• AI cost is bounded: exactly N calls per run, each for a specific generation task
• Debugging is console.log — read the output top-to-bottom
• Runs anywhere Node.js runs; pure stdlib plus one dependency (dotenv)

Cons:

• Rigid — adding adaptive behavior requires code changes
• Each new step is manual engineering work

Decision Criteria — What Actually Mattered

We ranked four criteria by importance for this specific use case — a daily pipeline that takes real-world actions with our consulting brand attached.

1. Predictability (Weight: Critical)

Every action this pipeline takes is visible to clients and prospects. A misdirected email, a hallucinated proposal, or a duplicate blog post causes real reputational damage. We needed identical control flow every single run.

2. Cost Ceiling (Weight: High)

Our playbook runs daily, 365 days per year. Agent orchestration adds 5–15 reasoning calls per run on top of the content generation calls. At our scale, that's the difference between $0/month (CLI subscription) and $50–150/month in API tokens just for orchestration overhead.

3. Debuggability (Weight: High)

When the 6 AM job digest shows zero proposals drafted, we need to know why in under 30 seconds. With a deterministic script, we check the log output and see exactly which step failed. With an agent, we'd parse a multi-turn conversation transcript hoping to find where reasoning went sideways.

4. Adaptability (Weight: Low)

The daily playbook steps change maybe once a month. The business process is stable. Adaptability is a real virtue for exploratory tasks — it's wasted on a pipeline that does the same six things every day.

Our Decision — Deterministic Script, AI for Generation Only

We chose Option C. Here's how it works in practice.

The Orchestration Layer: Pure JavaScript

The script maintains a simple action log and clock:

const actionsTaken = [];
const startTime = Date.now();

Every step is a plain async function called in sequence. There's no agent loop, no tool selection, no reasoning layer. The script knows what it's doing because we wrote the code:

async function draftJobProposals() {
  console.log('\n=== STEP 1: Job Proposal Drafting ===');

  const files = fs.readdirSync(JOB_REPORTS_DIR)
    .filter(f => f.startsWith('scraper-'))
    .sort()
    .reverse();

  if (files.length === 0) {
    console.log('[Jobs] No scraper results found');
    return;
  }

  const latestFile = path.join(JOB_REPORTS_DIR, files[0]);
  console.log(`[Jobs] Reading: ${latestFile}`);

  let data;
  try {
    data = JSON.parse(fs.readFileSync(latestFile, 'utf8'));
  } catch (err) {
    console.log(`[Jobs] Failed to parse: ${err.message}`);
    return;
  }
  // Sort by score, take top 5...
}

Notice what's happening: the orchestration is entirely deterministic. Read the latest scraper file. Parse the JSON. Sort by score. Take the top five. Only then call AI to draft the actual proposal text. The script decides what to do; the model decides how to write it.

AI as a Pure Function

We wrapped Claude CLI invocations as a stateless function — prompt in, text out, with built-in analytics and cleanup:

function callClaude(systemPrompt, userPrompt, model) {
  const id = `${Date.now()}-${Math.random().toString(36).slice(2)}`;
  const promptFile = `/tmp/playbook-prompt-${id}.txt`;
  const sysFile = `/tmp/playbook-sys-${id}.txt`;
  fs.writeFileSync(promptFile, userPrompt);
  fs.writeFileSync(sysFile, systemPrompt);

  try {
    const result = execSync(
      `${CLAUDE_BIN} -p --model ${model} --no-session-persistence ` +
      `--system-prompt "$(cat '${sysFile}')" < "${promptFile}"`,
      {
        timeout: 300000,
        maxBuffer: 20 * 1024 * 1024,
        stdio: ['pipe', 'pipe', 'pipe'],
        shell: '/bin/bash',
      }
    );
    return result.toString().trim();
  } catch (err) {
    console.error(`[Claude Error] ${err.message}`);
    return null;
  } finally {
    try { fs.unlinkSync(promptFile); } catch (e) {}
    try { fs.unlinkSync(sysFile); } catch (e) {}
  }
}

Key design choices here:

• --no-session-persistence: Every call is stateless. The model has zero memory of previous calls in the pipeline. This is intentional — we want each generation task isolated.
• 5-minute timeout: Content generation should complete in 30–90 seconds. A 5-minute ceiling catches hangs early.
• Temp file cleanup in finally: Prompts containing business data get deleted every time, even on failure.
• Model routing: The routeModel('daily-plan') call selects the cheapest model tier that handles this task well — typically Haiku-class for structured content generation.

This callClaude function is a pure transformation: system prompt + user prompt → text. It carries zero orchestration logic. The calling code decides when to invoke it, what context to pass, and what to do with the output.

Scheduling: systemd, the Orchestrator We Already Had

Every step in our daily pipeline runs on systemd timers — the same scheduler running our other 60+ automated tasks:

job-monitor.timer      → 8 AM EST    Job search
job-scraper.timer      → Every 6h    Board scraping
job-digest.timer       → 6 AM EST    Daily digest
research-runner.timer     → 1 AM EST    Research research pipeline
research pipeline-synthesizer.timer → 2:15 AM EST Cross-research pipeline synthesis

The daily playbook fires at 9 AM EST, after the job scraper and research pipelines have already deposited fresh data. This is implicit dependency management through scheduling — simple, visible, and battle-tested over months of production use.

The Real Cost Math

Our playbook makes 4–6 AI calls per run, each for content generation. Using model routing to select the appropriate tier:

• Script orchestration: 4–6 AI calls/day × ~2K tokens each = ~10K tokens/day
• Agent orchestration (estimated): 15–25 AI calls/day (planning + tool selection + content) × ~1.5K tokens each = ~30K tokens/day

Over a year, agent orchestration would triple our token consumption for this pipeline alone — and every additional reasoning call is a potential hallucination point in a system that sends real emails to real prospects.

Consequences — What Worked, What We'd Do Differently

What Worked

Operational reliability has been excellent. The playbook has run daily for months. Failures are always in a specific step (e.g., "Ghost API returned 503"), immediately visible in logs, and recoverable by rerunning that step. We have yet to encounter a failure we couldn't diagnose in under a minute.

Cost stayed at zero. Every AI call goes through the Claude CLI using subscription OAuth. The playbook comment says Cost: $0 and that's been accurate. Agent orchestration would have forced us to API billing just for the reasoning overhead.

The action summary email is genuinely useful. Because every action is tracked in a simple array (actionsTaken.push(...)), the end-of-run summary is exhaustive and accurate. An agent would need to self-report its actions — and agents are unreliable narrators.

What We'd Do Differently

Error recovery is manual. When Step 3 fails, we rerun the entire script. A proper retry mechanism per step — even a simple one — would save time. We'd add per-step try/catch with configurable retry counts.

The execSync pattern blocks. Steps 1 and 2 could run in parallel since they have separate dependencies. We stayed sequential for simplicity, but Promise.all on independent steps would cut total runtime by 30–40%.

When to Reconsider This Decision

We'd move toward agent orchestration if any of these conditions became true:

• The step count exceeds 15–20, making the combinatorial complexity of manual orchestration burdensome
• Steps require dynamic ordering — e.g., "publish the blog post first if subscriber count dropped, otherwise prioritize proposals"
• Cross-step reasoning becomes essential — e.g., "the tone of the outreach email should reference what we discovered in the job analysis"
• The business process changes weekly, making the engineering cost of script updates unsustainable

For now, six stable steps with monthly changes keeps deterministic orchestration firmly in the sweet spot.

Conclusion

The industry's current reflex — "make it an agent" — optimizes for impressiveness over reliability. For daily automation that sends real emails, publishes real content, and represents your brand to real prospects, deterministic orchestration with targeted AI generation delivers better predictability, lower cost, and faster debugging.

The principle is straightforward: use AI where generation is needed, use code where control flow is needed. An agent loop is the right tool when the sequence of actions requires intelligence. When the sequence is known and stable, a script is faster to build, easier to debug, and cheaper to run — every single day, for years.

Our production playbook is proof: 6 steps, 4–6 AI calls, $0/month, months of reliable daily execution across 25 services. The boring choice was the right choice.

Need help building AI agent systems or designing multi-agent architectures? Ledd Consulting specializes in autonomous workflow design and agent orchestration for enterprise teams.