A SaaS founder asked us to second-opinion a roadmap his CTO had come back with after an "agentic AI" vendor pitch. The plan was eighteen agents, a planner LLM, an executor LLM, a critic LLM, six months of build, and a 5x increase in their model spend.

The current product was a chatbot that answered customer FAQs about their billing portal. About 80% of incoming questions were five variations of "how do I export my invoice as PDF." The remaining 20% routed to a human agent because the chatbot did not know how to.

We told the founder to add a sentence to the existing prompt and ship the agentic plan to the backlog.

This is the conversation that comes up almost every week now. Vendors are pitching agents at every B2B SaaS founder. Most of those founders do not need agents. Here is the framework Sapota uses to decide.

What an AI agent actually is

Strip away the marketing and an agent is three things bolted onto an LLM:

• Tools: the ability to call external functions (search, query a database, run code)
• Memory: state that persists across multiple LLM calls within a task
• Autonomy: the LLM decides what to do next, not the developer

The autonomy part is what makes it an agent. A regular RAG pipeline retrieves chunks and generates a response in a single fixed flow. An agent decides on each step whether to retrieve more, call a tool, ask for clarification, or finalize the answer.

That capability is genuinely useful for some tasks. It is also five to fifteen times more expensive per query than a regular LLM call, two to ten times slower, and significantly harder to debug. The math has to work out before the agent earns its place.

The single-question test

Sapota's filter is one question: would a single, well-written prompt complete this task?

If yes, do not build an agent. Use the prompt.

If no, ask: would a fixed two-step pipeline (retrieve, then generate) complete it? If yes, build a RAG pipeline, not an agent.

If still no, ask: does the task actually require dynamic decisions about what to do next, or is the developer just unsure what the steps should be? If the latter, write the steps down. The discomfort of designing the flow is not a reason to delegate it to an LLM.

If after all three questions the answer is still "yes, this needs autonomy," then an agent is the right tool. In our experience, this filter eliminates 70% of "we need an agent" conversations.

What the founder's chatbot actually needed

The 80% of repeat questions about invoice export were a prompt problem. The original prompt was something like:

"You are a helpful customer support assistant. Answer the user's question."

The fix was to add:

"If the user asks about exporting invoices, respond with: 'Click Settings → Billing → Export. Choose PDF format and the date range you want.' Then ask if they need anything else."

That single line solved 80% of the inbound volume. No agent needed. No vendor needed. Three minutes of work.

The remaining 20% (the questions the chatbot did not know how to handle) split into two categories. About 12% were specific to a customer's account state, and those genuinely needed a tool call to the user database. The remaining 8% were edge cases that should have been routed to humans anyway.

The right architecture was a single-prompt chatbot with one tool (account lookup) and a fallback to human handoff. Two days of work. Cost per query stayed under $0.005. The agentic pitch had estimated $0.05 per query and a six-month build.

When agents are actually the right call

We are not anti-agent. The tasks where Sapota does recommend building an agent share three properties:

Genuinely multi-step decisions, where step N depends on the result of step N-1. Research synthesis, where the next search depends on what the first search returned. Code refactoring, where the next file depends on the changes already made. Customer onboarding triage, where the routing depends on data pulled from multiple systems.

Tools the LLM needs to coordinate. A single tool call is not an agent, it is a tool call. An agent earns its complexity when the LLM is choosing between three to seven tools and combining results. Customer support that pulls from CRM, KB, billing system, and shipment tracker. Sales research that combines LinkedIn, news, financial data, and CRM history.

Costs that justify the overhead. Agentic infrastructure adds $0.02 to $0.20 per task in LLM costs alone, before counting development and operations. That is fine for a research assistant a sales engineer uses ten times a day. It is not fine for a chatbot that needs to handle 50,000 queries a month at $0.005 each.

The pattern we keep seeing

The founder mistake we see most often is treating "agent" as a level of sophistication rather than a tool with specific use cases. The pitch sounds compelling: autonomous, intelligent, self-improving, adaptive. The reality for most B2B SaaS products is that the queries are repetitive, the data sources are limited, and the user expectations are predictable.

A well-written prompt with a single tool and a faithfulness gate beats an agent on cost, latency, and reliability for the bottom 80% of "AI feature" use cases. The 20% where agents win is genuine and important, but it is not 100% of the use cases.

The vendor selling the agentic platform does not have an incentive to tell you this. The pitch is "agentic AI is the future." The pitch is also "buy this platform from us." Both can be true. They can also be true that this specific product does not need to participate in that future yet.

The Sapota recommendation

Before committing to an agentic build:

• Run the single-question test. Be honest about whether autonomy is genuinely required.
• Estimate the cost per task at production volume. Multiply by your projected query rate. Compare to current cost.
• Audit the existing prompt and tool setup. Most "AI feature gaps" are missing prompt instructions, not missing agents.
• If the answer is still "we need an agent," start with one agent and one tool. Do not build the eighteen-agent system the vendor proposed. The single-agent baseline is your reference point for whether the multi-agent architecture is worth its overhead.

Build small, measure, expand. The agentic pattern is real and useful. It is also frequently the wrong answer to the question being asked.

If a vendor is pitching agents at you

If your team is being told that AI agents are the next quarter's roadmap, the question to ask before signing is what fraction of your production queries actually need autonomy. If the vendor cannot answer that with your data, they are pitching a product, not a solution.

Sapota offers a one-week query distribution audit that takes your production query log, classifies the queries by complexity, and produces a sized recommendation for which fraction needs an agent and which is better served by a single prompt with proper tools. The output is a budget-and-architecture document the team can take to the vendor or the board.

Reach out via the AI engineering page with your current AI architecture and approximate query volume. The diagnostic conversation almost always reframes the question from "agents or not" to "where exactly is the autonomy actually needed."