Why we kill 80% of the agent ideas our clients bring us

A client comes in with an AI idea. It's usually phrased like this: "We want an AI agent that handles customer support."

We kill roughly four out of every five of those conversations before they reach a statement of work. The client is usually surprised. Some of them are annoyed. A few are relieved — they suspected the thing they were being sold didn't make sense.

Here's how we decide what stays.

The question that kills most agent ideas

Can a deterministic state machine do the same thing?

If the answer is yes, or even "mostly yes," the agent is the wrong tool.

Agents are appropriate when you genuinely need an LLM's strengths: open-ended reasoning over unstructured input, creative generation, extraction of intent from ambiguous natural language, or dynamic tool composition where the tool sequence can't be predicted. They are inappropriate for structured intake, multi-step form filling, routing, classification into a fixed taxonomy, or any workflow where a finite-state machine will behave more predictably.

Most "agent" requests are actually structured workflow requests with a chat interface bolted on top. The chat interface is what the client actually wants. The agent underneath is usually the wrong implementation.

The three failure modes we've watched repeatedly

1. The $40-per-conversation support bot

A client built a "customer support AI agent" with a frontier model and a vector-searched knowledge base. Every conversation called the model four times on average. Average cost per conversation: roughly 40 cents. Monthly cost for 10,000 conversations: $4,000 that used to be $400 of human-agent time. And the human was better at hard cases.

What they actually needed was a deterministic FAQ lookup for the 70 percent of queries that are repeat questions, with an LLM fallback only for the 30 percent the lookup missed. Same quality, one-eighth the cost.

2. The six-step intake form with a chat wrapper

A client had a clinical intake form. Six fields, one validation per field, one downstream action. They built an agent to "have a conversation" and extract the fields.

We replaced it with a form. The form had higher completion rates, zero hallucination, full validation, and worked offline. The chat wrapper made the client feel modern. The form made the users feel respected.

3. The infinite-retry debugging loop

A client built an agent that could "fix its own errors." It could. It just took six retries and $3 per attempt. The underlying problem was a schema mismatch in the upstream API. A deterministic exception handler with a schema-sanity check would have caught it in under a second.

The pattern: agents make failure expensive because retry is stochastic. Deterministic code makes failure diagnosable.

The 20 percent that stays

Agents are the right answer when the task genuinely requires reasoning over unstructured input. Some examples from production engagements:

Contract analysis. Read a 40-page vendor contract, extract payment terms, indemnity clauses, and auto-renewal dates. No deterministic parser can do this — contract language is too varied. This is an LLM task.

Multi-source research. Given a prospect name, pull LinkedIn, news, Crunchbase, and the company blog, synthesize a one-page brief. The synthesis step is LLM. The data fetching is deterministic.

Code review on architectural intent. A linter can catch syntax. An LLM can ask "does this function belong in this module?" That's judgment, not pattern matching.

Creative generation. Marketing copy variants, image captions, translation where cultural context matters. The whole point is that the output shouldn't be deterministic.

The 80/20 Hybrid rule

The way we build production agent systems is to let deterministic code do the 80 percent it's good at — auth, CRUD, validation, routing, scheduling, state management, retries, observability, cost accounting — and reserve the LLM for the specific decision points where reasoning actually beats rules.

In practice, that means a typical "agent" we ship is mostly a workflow engine with an LLM node embedded at the one or two steps where open-ended reasoning is required. The workflow engine is Step Functions, or LangGraph, or a hand-rolled state machine. The LLM node is bounded, observable, and cost-capped.

This design has three consequences the client feels immediately:

1. Cost is predictable. You can price a support ticket. You can't price an open-ended conversation.
2. Failure is debuggable. A state-machine failure points at a specific node. An agent failure points at a prompt that needs rewriting, maybe.
3. The product is testable. Deterministic code has deterministic tests. Agents need evals, and evals are engineering work most teams don't budget for.

How we handle the initial conversation

When a client asks for "an AI agent," we ask four questions before we quote:

1. What exactly is the user trying to accomplish — in a sentence, in their words?
2. What are the inputs? Structured (form fields)? Semi-structured (emails)? Unstructured (voice, documents)?
3. What are the outputs? A fixed taxonomy? A synthesized summary? A generated artifact?
4. What happens if the agent is wrong 1 percent of the time? 10 percent? How do you catch the wrong cases?

If answer 3 is "a fixed taxonomy" and answer 4 is "we'd need to catch 99 percent of errors," we recommend a workflow with an LLM boost, not an agent. If answer 2 is "unstructured" and answer 4 is "we can tolerate a human review," we recommend an agent with a review queue.

It is the right tool for a narrow set of problems. It is the wrong tool for most of what it's sold to solve.

---

The AppsTango method is called the 80/20 Hybrid for a reason. If you're about to commit to an agent build, spend 30 minutes with us first. We'll tell you honestly whether it's the right shape for your problem — and if it isn't, we'll sketch the shape that is.