Should You Build an Agent for That?

Gartner predicts more than 40% of agentic AI projects will be cancelled by the end of 2027, killed by escalating costs, unclear business value, or risk controls nobody thought through before the build started.

S&P Global found something similar looking backward instead of forward: 42% of companies abandoned most of their AI initiatives before they ever reached production in 2025, up from 17% the year before.

The failure rate more than doubled in a single year.

Why did so many AI projects fail? We could point to things like internal alignment and readiness, or even shortcoming in the models.

Many of them failed because nobody asked, before writing a line of code, whether the workflow deserved an agent.

I’ve lived both sides of that question. At one point I had two agents running. Then I built my way up to twenty, chasing every task I could plausibly hand off. Now I’m back down to somewhere around 5-10 agents.

I only use 3-5 agents daily: engineering, support, market listening, content drafting, scrum. Other agents still run. Some of them I still use 1-2x per week. Others collect dust in the Github graveyard.

Watching that number climb and then shrink taught me something I now tell clients before I tell them anything else: the single most valuable advice I give is when not to use AI.

That advice has a real cost attached when I get it wrong. I was working with a client in financial services on OFAC screening, checking transactions against sanctions lists.

At first, the instinct is obvious: this is text matching and pattern recognition, hand it to an LLM.

After looking at the workflow more closely, I told them not to. If the model fabricates a match, or misses one, and your team acts on that output, you’re the one who answers for it. Claude isn’t the one who goes to jail.

The question to be asked before building any agent is whether this specific task is ripe for an agent, or whether an agent is the wrong tool wearing the right buzzword?

Factors to consider for building an agent

I use four factors to make the proper decision:

1) Frequency of action. Does this happen often enough to matter?

A task you do once a quarter isn’t worth agent-grade engineering no matter how annoying it is.

I prioritize by frequency first: the agent that touches my Linear project daily gets built long before the agent for onboarding a new hire, even though onboarding feels more urgent when it’s happening.

Frequency is what turns build effort into compounding return instead of a one-time favor to yourself.

2) Complexity of work. Does the job require reasoning?

Some tasks look like judgment calls and turn out to be lookup tables.

I learned this the hard way building interview flows for my app, Baohua.

My first version had the model dynamically generate questions based on the user inputs, because that felt like the “AI-native” way to do it. It required constant tuning, burned tokens on every turn, and the questions still drifted in ways I had to keep pruning by hand.

I replaced it with a fixed question bank, built in a single session. Same interview quality, none of the maintenance.

If 90-95% of a task is solvable with a decision tree or a lookup table, build the decision tree. Spend the agent budget somewhere the reasoning is required.

3. Hallucination impact. What’s the cost of the model getting it wrong?

This is the OFAC test generalized: what happens when the model is confidently wrong?

In some domains a wrong answer is a bad Tuesday, but your organizational checks and insulation take care of you. A bad PR is caught by a human reviewer. Or a sloppy PRD can be corrected by a good PM.

In other cases, it’s a compliance violation, a misdiagnosis, a sloppy contract that costs you a deal.

There could be promising areas for AI, but the risk is too great to give the agent automation. Things like human-in-the-loop, reviews, and partial automation may help. In other cases, it’s not worth using AI.

4. Net work impact. Is the final agent a net positive on workloads, or a time suck?

Coding is the clean example of a task where this holds up well. Foundation models are well-tuned for it, the guidance overhead is low, and the ROI on agent-generated code is real and repeatable across almost every team I work with.

Writing, especially writing PRDs, is the opposite case. This is where most of the AI slop I see comes from: teams generate a document that reads like a PRD but isn’t one, because no amount of context engineering gets a model to the deep truth of what your product needs to be.

You can feed it as much context as you want, but it will always give you a sloppy PRD that doesn’t get to the truth.

I find that AI helps me draft PRDS, but I would never let it write the PRD for me.

Some tasks, more prompting doesn’t fix. It produces a more convincing miss.

Examples of agent use cases

Here’s that same four-question checklist run against a few use cases I see constantly. The ratings below are my own read walking through each one:

Daily standup: The cost of a poorly written standup is low, and it’s not hard to get AI to cleanly collate information across systems like Git and Linear. The reasoning an agent does across tickets, PRs, and emails genuinely helps

Customer support: An agent can help reduce a lot of the early noise on support triage, searching through knowledge bases, code bases, and previous conversations to help human support analysts more quickly address inquiries.

Sanctions screening: While there’s a lot to be gained by using AI for compliance screening, most of this work is through lookup tables and needs determinism. AI could help with text parsing, but the penalty of being wrong here is very high.

PRD writing: PRD writing is probably the most controversial take. I use AI to help me draft PRDs and they aren’t awful. But I don’t have a dedicated agent to help me dial in PRDs so that I can crank them out.

I have a simple skill file that helps me do a first draft, and then I carry PRDs the rest of the way. To me, it’s a waste of time trying to tune skills files and context engineer a good PRD. There’s too much nuance required to write a good PRD and this is what you need a human PM for.

Running the evaluation for yourself

This is the actual evaluation I run with clients before we write anything, and it’s usually a faster conversation than people expect. Once you separate “can AI attempt this” from “should this specific task carry an agent,” most of the ambiguity disappears.

A few well-designed agents in the right places can give you a genuinely outsized return.

Organizations don’t need fleets of 500 agents quietly running, most of them abandoned within two years by Gartner’s math. They need one or two that move the needle on day to day work, and the discipline to say no to the rest.

Before you greenlight the next agent, run it through these four questions first. Your future tokens will thank you.