When an AI Agent Is the Wrong Tool

I often talk clients out of building AI agents when a simpler system will do. That's not because I don't like the work — I do — but because the right solution is often simpler, faster, and cheaper than what they came in asking for.

The pitch is always the same: "We need an AI agent to automate X." And sometimes they're right. But more often, what they actually need is a rules engine, a SQL query, or a Python script that runs on a schedule. The difference matters. An agent that shouldn't exist becomes technical debt you're stuck maintaining, and the gap between what it costs to run and what it delivers never closes.

When I say no

I worked with a firm that wanted an agent to review legal invoices for billing guideline compliance. They'd been manually checking hundreds of pages each month — partner names, block billing violations, task code errors, hourly rate caps. The kind of tedious, high-stakes work that feels like it was made for AI.

Except most of it wasn't. On billing-guideline work like this, I consistently see about 70% of the rules turn out to be deterministic: if the rate exceeds $X, flag it. If the time entry lacks a task code, flag it. If the block exceeds four hours without a breakdown, flag it. You don't need an LLM to check whether a number is above a threshold. You need a parser and a ruleset.

We built a hybrid: a document extraction pipeline (Anthropic Claude for OCR and structure) that fed into a rules engine. The LLM handled the messy part — turning invoice PDFs into structured JSON. The rules engine handled everything else. It ran faster, cost substantially less per invoice than a full agent approach would have, and never hallucinated a false positive on a deterministic rule.

The client got their compliance checks automated. I didn't sell them an agent they didn't need.

The agent tax

Every time you introduce an LLM into a workflow, you're accepting:

Latency. Even the fastest models take longer than a conditional branch.
Cost. API calls add up. A rules engine runs for free after you write it.
Nondeterminism. The same input can produce different outputs. That's fine for drafting emails. It's a liability when the output controls money or compliance decisions.
Monitoring overhead. You need evals, you need logging, you need a way to catch drift when the model updates or your prompts degrade.

If the problem you're solving is deterministic — if you can write down the exact logic in pseudocode and it covers 80%+ of cases — you probably don't need an agent. You need that logic in code.

When I say yes

A logistics company asked me to help them route inbound customer emails. They got everything from "Where's my shipment?" to "I need a custom quote for 50 pallets to Buenos Aires with a delivery window on December 3rd" in the same inbox.

The old system used keyword matching. It worked poorly. "Shipment" appeared in complaints, tracking requests, and sales inquiries. "Quote" showed up in replies to old quotes and new requests. Context mattered, and keyword rules couldn't encode it.

This is what agents are actually good at: reasoning over ambiguous input where the right action depends on intent, not pattern matching. We built a FastAPI service with a classification agent (LangGraph + GPT-4) that read the email, identified intent, extracted entities, and routed it to the right queue. It handled edge cases — multi-intent emails, follow-ups that referenced prior threads — that would've taken hundreds of brittle rules to cover.

Was it more complex than a rules engine? Yes. Did it justify the complexity? Also yes. The alternative was hiring someone to triage emails full-time, or continuing to deal with the constant misroutes their keyword system produced.

What to build instead

Before you reach for an agent, ask:

Can I write the logic as a decision tree? If yes, write it as code. It'll be faster, cheaper, and easier to debug.
Is the input always structured? If you're working with databases, APIs, or CSVs, you probably don't need an LLM. Use SQL, Pandas, or whatever query layer already exists.
Does it need to run in real time? Agents are slow. If you're embedding this in a user-facing flow and you need sub-second responses, look hard at whether you can precompute, cache, or simplify.
Can I get 80% of the value with 20% of the agent? Sometimes the right move is using an LLM for one hard step (document parsing, intent classification) and handling everything else deterministically.

The best automation is the simplest one that works. I've seen teams burn weeks tuning an agent that a well-written script could've replaced. I've also seen teams try to encode business logic in 300 if-statements when a small language model would've done it in three lines of Python.

When it's actually worth it

An agent earns its keep when:

The input is unstructured (emails, PDFs, transcripts) and you need to extract meaning, not just keywords.
The logic is too complex or too fluid to encode as rules. If the business can't clearly explain the decision process, a model might generalize better than brittle code.
You're replacing human judgment in a workflow where latency and cost are acceptable tradeoffs for accuracy and scale.

If those don't apply, start simpler. You can always add the LLM later.

A short pitch

I work with legal, finance, and ops teams who need production AI systems — agents when it makes sense, and deterministic automation when it doesn't. If this matches how you think about these problems, let's talk. Email me at bilaltehseen@gmail.com.