The fastest way to make an AI project expensive is to start by saying: “Let’s build an agent.”
Sometimes you do need one but a lot of teams are adding agent logic before they have clarified what the
system actually needs to know, access, or do.
A more practical way to scope an AI project is to work backwards from the job:
1. Does it mainly need to understand, write, summarize, classify, or work
through messy information?
Start with an LLM.
2. Does it need answers grounded in changing company documents, policies, or
internal knowledge?
Add retrieval.
*But if it needs a live order status, customer balance, or CRM record, a direct
system call is often more useful than RAG.
3. Does it need to access business tools or systems?
Define the permissions and action boundaries first.
*A direct API may be enough. MCP becomes useful when you want a more standard, reusable way for AI
applications to connect with tools and data.
4. Does it need to choose between steps, use several tools, and handle
exceptions along the way?
That is when agent design starts to make sense.
For example, a support assistant answering questions from documentation may
only need an LLM + retrieval. But a system that checks an account, applies policy rules, updates a ticket,
requests approval, and follows up with a customer may need agentic
orchestration around it. The production difference is not just whether the AI can use tools.
It is where you let the model use judgment, and where the system needs to stay
in control through clear rules, permissions, approvals, and handoff paths.