Modern Automation with LLMs: Workflows, Tools and Human-in-the-Loop

Classic automation needs structured input. Most business work starts as unstructured text: an email, a PDF, a chat message. LLMs close that gap. The craft is to use the model only where language is involved and to keep everything else deterministic, observable and, where it matters, approved by a person.

What LLMs change about automation

Rule-based automation and robotic process automation (RPA) work well when inputs have a fixed shape. A form field maps to a database column, and a button sits at the same place on the screen every time. They break down when the input is a customer writing "the parcel came yesterday but the blue one is missing and I need it before Friday". No regular expression reliably turns that into an order ID, a problem type and a deadline.

An LLM can. It reads free text in many languages, copes with typos and missing context, and returns a structured result. That makes a large category of "a person reads it and decides what to do" work automatable for the first time.

The trade-off is that the model is probabilistic. It is usually right, sometimes wrong, and occasionally confidently wrong, which is a hallucination. Good LLM automation is therefore mostly engineering around the model: constrain the output, validate it, route uncertain cases to people and measure everything.

The core patterns

Almost every LLM automation combines a handful of building blocks:

• Classify: assign one label from a fixed set, such as intent, department, sentiment or spam/not spam.
• Extract: pull named fields out of text or documents: invoice totals, contract dates, order numbers.
• Route: pick the next step or team based on the classification and extracted fields. Plain code usually does this best.
• Summarise: condense a long thread, call transcript or report for the person who acts next.
• Draft: write a reply, a ticket description or a report section for a human to approve or edit.
• Act: call a business system: create a ticket, update a CRM record, issue a refund. The model can choose the action through tool calling, but the action itself runs in ordinary code.

The first four are read-only and easy to make safe. Drafting is safe if a person reviews the draft. Acting is where mistakes cost money, so it gets the strictest controls.

Anatomy of an automated workflow

A production LLM workflow has four parts:

1. Trigger. A new email, a webhook, a file landing in a bucket, a schedule.
2. Orchestrator. The engine that runs the steps in order, stores state, retries failures and records what happened.
3. LLM steps. Narrow, single-purpose calls with a fixed prompt and a structured output schema.
4. Deterministic actions. API calls to business systems, using only validated fields.

The orchestrator can be a visual tool or code. Visual tools are faster to start with and easier for operations teams to read. Code-first engines give you version control, tests and durable state for long-running processes.

For a handful of steps, a queue and a worker in your own codebase may be enough. Reach for a dedicated engine when you need retries with state, waiting for humans for days, or an audit trail for every run.

Structured outputs and validation

An LLM step is only useful to the rest of the workflow if its output is machine-readable. Ask for JSON that matches a JSON Schema. Many model APIs can constrain generation to a supplied schema (OpenAI calls this Structured Outputs), so the reply parses and has the right shape. They do not guarantee that the values are right: a valid-looking order ID can still be invented.

So validate twice: let the API enforce the shape, then check the content in your own code. In Python, Pydantic does both jobs. One model class produces the JSON Schema to send to the API and validates the reply. If validation fails, send the errors back to the model once or twice, and then give up and pass the item to a person.

from typing import Literal
from pydantic import BaseModel, Field, ValidationError

class TicketFields(BaseModel):
    intent: Literal["refund", "delivery", "technical", "billing", "other"]
    urgency: Literal["low", "normal", "high"]
    order_id: str | None = Field(default=None, pattern=r"^ORD-\d{6}$")
    product: str | None = None
    language: str = Field(description="ISO 639-1 code, e.g. 'en'")
    summary: str = Field(max_length=300)

def call_llm(system: str, user: str, schema: dict) -> str:
    """Placeholder: call your provider with structured output enabled
    for `schema` and return the raw JSON text of the reply."""
    raise NotImplementedError

def extract_fields(email_text: str, max_attempts: int = 3) -> TicketFields:
    schema = TicketFields.model_json_schema()
    system = ("Extract support ticket fields from the email. "
              "Use null for anything the customer did not state. Never guess IDs.")
    user = email_text
    for _ in range(max_attempts):
        raw = call_llm(system, user, schema)
        try:
            return TicketFields.model_validate_json(raw)
        except ValidationError as err:
            # Show the model its mistake and ask for a corrected object
            user = (f"{email_text}\n\nYour previous JSON was invalid:\n{err}\n"
                    "Return a corrected JSON object only.")
    raise RuntimeError("validation failed: send to the human review queue")

Two details matter here. The Literal types keep the model inside the label set your routing code understands. The order-ID pattern catches a common failure in which the model invents an identifier that looks plausible. Provider schema enforcement usually supports a subset of JSON Schema, so check which keywords yours accepts and enforce the rest in code. Schema checks, policy rules and content filters together form the guardrails of the workflow.

Deterministic workflow or agentic step?

In a workflow, the developer fixes the sequence of steps. In an agent, the model decides which tools to call and in what order. Anthropic's guidance on building agents makes the same distinction and recommends the simplest option that works. In automation, that is usually a workflow.

Workflows are cheaper, faster, easier to test and easier to explain to an auditor. Use an agentic step only when the path cannot be known in advance. An example is investigating why an account was double-charged, which may need a look at payments, then subscriptions, then a support history that differs from case to case. Even then, keep the agent inside a box. Give it read-only tools where possible, a step limit and a structured final answer that the workflow takes over again. How such loops are built is covered in agents, tool calling and MCP and harnesses.

Worked example: support email triage

Consider a mid-sized online shop that receives thousands of support emails a week. The goal is not to replace the support team. It is to remove the reading, sorting and first-draft work so the team spends its time on decisions.

Step by step:

1. Classify. Pick the intent and urgency from fixed label sets. This is a pure choice question, so it does not need a generative model. A decision model or a small fine-tuned classifier can answer it faster and more cheaply, with a probability you can use as a threshold; see decision models.
2. Extract. Fill the TicketFields schema from the code above. Look up the order ID in the shop database. If it does not exist, treat the extraction as failed.
3. Route. Ordinary if statements on validated fields: legal threats and complaints go to a team queue, refunds above a set amount go to a supervisor, and everything else continues.
4. Draft. Generate a reply grounded in the relevant help-centre articles and the order's actual status, retrieved as described in embeddings and RAG.
5. Approve. A member of the support team sees the email, the extracted fields and the draft side by side, then approves, edits or rejects. Only then does the workflow send the reply and update the ticket.

The extraction step for a typical refund email returns an object like this, which the routing code can trust because it has passed validation:

{
  "intent": "refund",
  "urgency": "normal",
  "order_id": "ORD-104233",
  "product": "Trail running shoes",
  "language": "en",
  "summary": "Received the wrong size; asks for a refund rather than an exchange."
}

Designing the human in the loop

Human-in-the-loop design decides where people look and how much of their time it costs. The three common mechanisms are:

• Approval queues: every item of a given type waits for a person before any irreversible action. This is the right default for new workflows and for anything that sends messages or moves money.
• Confidence thresholds: items the system is sure about go through automatically, uncertain ones go to review, and the rest are handled manually.
• Sampling: a random share of auto-approved items is reviewed anyway, so you notice when quality drifts.

Thresholds only work if the scores mean something. A score of 0.9 should be right about nine times in ten, a property called calibration. Probabilities from classifiers and decision models can be checked and tuned for calibration. A generative model asked to "rate your confidence from 1 to 10" often produces overconfident, poorly calibrated numbers. Every reviewer decision is also a free label: store it and use it to re-tune thresholds and extend your test set.

Reliability engineering

LLM APIs are network services with rate limits, latency spikes and occasional outages, and the model's output changes with every prompt edit. Treat each LLM step like any other unreliable dependency:

• Retries with backoff for rate-limit and server errors, with jitter so that parallel workers do not retry in lockstep. Validation failures get a separate, small retry budget.
• Idempotency. Triggers fire twice and workers crash halfway. Key each run on a stable ID, such as the email's message ID, and make side effects safe to repeat, so no customer gets two replies or two refunds.
• Timeouts on every model and API call, so one slow request cannot block a queue.
• Fallbacks: a second model or provider for outages, and a human queue as the final fallback for everything.
• Cost and rate controls: concurrency limits, token caps per step and a daily budget alert. Use the smallest model that passes your tests for each step.
• Logging and tracing: record the prompt version, model name, inputs, outputs, validation result, latency and cost for every step, linked by one run ID. Without traces, "the bot sent a strange reply" cannot be debugged.

Durable execution engines such as Temporal handle much of this for you. Each step's result is persisted, failed steps are retried by policy, and a workflow can wait days for a human approval and then resume where it stopped.

Measuring success

Before launch, build an evaluation set: a few hundred real, anonymised items labelled by the people who do the work today. Run every prompt or model change against it, just like a regression test suite; these evals are what make changes safe. Measure per step, because a good final result can hide a weak step.

• Accuracy per step: classification accuracy and confusion between labels, and field-level accuracy for extraction.
• Edit rate: the share of drafts people change before approving, and how much they change. This is the most honest measure of draft quality.
• Escalation rate: the share of items sent to people, by reason.
• Time saved: handling time per item before and after, measured, not estimated.
• Cost per item and end-to-end latency.

When not to use an LLM

If the input is already structured, such as a form submission or an API payload, use plain code. If the rule is stable and complete, such as tax calculation or eligibility based on fixed criteria, write the rule. If the task is exact arithmetic, a lookup or a join, use a database. If the volume is huge and the question is a simple label, a small classifier or decision model is cheaper and easier to calibrate. LLMs earn their place on messy language, and that is where you should spend them.