Agents in production: when LLM workflows replace integrations

For most of the last fifteen years, “automating a workflow” meant building an integration. Two systems that needed to talk to each other got connected by code: API client, transform layer, error handling, retry logic, observability. The integration was deterministic, testable, and as durable as the upstream APIs.

Some workflows can’t be automated this way. The data is unstructured, the upstream systems don’t expose useful APIs, the rules change too often to encode, or the human-in-the-loop is doing judgement work that no API surfaces. For these workflows, the choice has historically been: pay humans to do them, or live with the gap.

LLM agents have made a third option viable for a meaningful share of these workflows. This post is about when that third option is the right answer, and when it isn’t.

Where agents win

Three patterns we ship most often:

1. Unstructured-input ETL. The upstream is PDFs, emails, web pages, or chat transcripts. The downstream needs structured data. Building a parser per-source is expensive and brittle. An LLM agent extracts and normalises across sources, with a human review queue for low-confidence outputs.
2. Long-tail integrations. A workflow that hits 30 vendors, each with a slightly different API or no API at all. Writing 30 integration clients is a 12-month project. An agent that can navigate web UIs and email-based workflows handles the long tail at meaningful cost reduction, with the deterministic clients reserved for the top 5 vendors by volume.
3. Decision-with-context workflows. A human currently makes a decision after reading three documents, checking two systems, and applying judgement. The agent reads the same context, drafts the decision, and routes to a human reviewer. Throughput per reviewer goes up 3–5×.

Where agents lose

Three patterns where we’ve talked clients out of the agent approach:

1. High-volume, low-judgement transactions. If the workflow is well-structured and high-throughput, a deterministic integration is faster, cheaper, and more reliable than an agent. Agents are an LLM call per transaction; integrations are essentially free per transaction.
2. Strict compliance / audit boundaries. Some workflows require deterministic, traceable decision logic. “The LLM decided” is not an answer regulated industries can give. Agents can still play a role here as decision-support, with the final decision deterministic.
3. Continuously evolving environments. If the upstream system changes weekly (e.g., a vendor’s web UI), the agent needs continuous evaluation and prompt tuning. Some clients have appetite for this; many don’t.

The cost-of-evaluation is the most underestimated line item in production agent deployments. We budget for it explicitly in every Agents engagement.

What “production-ready” actually requires

A toy agent that works in a notebook is not a production agent. The delta between the two is the engineering work that makes our Agents service line distinct from “we wrote a prompt for you.”

Five components every production agent needs:

1. Evaluation harness. A test set of representative inputs and expected outputs. Every prompt change runs through the harness; regressions block deployment.
2. Observability. Per-call traces, per-call cost, per-call latency, structured error categorisation. Without this, you can’t diagnose why the agent failed yesterday.
3. Rollback procedure. When an agent regresses in production, you need a one-command rollback to a known-good version. Most teams don’t build this; they need it.
4. Human-in-the-loop integration. A review queue, an approval flow, an audit log. The agent is a recommendation; the human is the decision (in most regulated contexts).
5. Budget controls. Per-tenant rate limits, per-day cost caps, runaway-detection alerts. LLM costs can compound 100× from a bad prompt or a feedback loop. The controls exist to prevent the surprise.

A typical Agents engagement ships all five over 6–10 weeks at a fixed price. Without all five, the agent is a prototype, not a production system.

A reference engagement

A recent client: a mid-market staffing agency where account managers spent 2–3 hours/day reading inbound RFP emails and producing structured bid responses. The work was judgement-heavy (matching candidates to roles), the volume was 80–120 RFPs/day, and the team had been growing the function by hiring more account managers.

We built an agent in 8 weeks: read inbound RFP, extract role requirements, query candidate database, draft a structured bid response, route to account manager for review and send. Account manager throughput went from ~12 RFPs/day to ~50 RFPs/day. The cost per bid dropped 70%, with bid-win rate roughly stable.

The engagement is not in our public case studies because the client asked us not to publish. The shape is representative.

When to start with agents vs integrations

If the workflow is structured, high-volume, and has APIs on both ends — write the integration. It will be cheaper to run and more reliable.

If the workflow is unstructured, judgement-heavy, or hits a long tail of upstream systems — start with the agent. The economics tip towards the agent at lower volumes than they used to.

If you’re not sure — a Strategy engagement (4 weeks, fixed price) produces a written brief recommending the right architecture. The decision is more durable than the prototype it would otherwise produce.

Read more: /agents/ · /case-studies/agency-bid-automation · /strategy/