For anyone working with data — analysts, scientists, engineers — at any level.
I’ve seen companies and teams scrambling to adapt to the age of AI. The mandate arrives fast: use agents, build and share skills, move autonomously. The pressure is real, and so is the enthusiasm.
So is the misuse.
What I keep seeing is an over-reliance on powerful LLMs for tasks that don’t need them — burning tokens on work that a 20-line script would handle better, faster, and cheaper. The problem isn’t the technology. It’s that most teams haven’t drawn the line between what an agent should reason about and what a script should simply execute.
I love LLMs and agents. One edits my writing — since I’m not a native English speaker, I used to hesitate before publishing. Having an agent act as an editor changed that. But that’s exactly the right use of the tool: it requires language judgment, not deterministic execution. The cases I’m about to describe don’t.
Use scripts for deterministic tasks #
If you want to extract information from a Tableau dashboard’s XML, process Jira tickets, or scrape a website — don’t hand the whole job to an agent. The raw text you extract will be many times larger than the information you actually need. Sending it all to an LLM is expensive and imprecise. Reports suggest up to 70% of tokens are wasted, most of them spent exploring context and learning the code it has to run — work a script would have done for free.
The better approach: use an NLP script to process and filter the data first, structure the output as JSON or YAML, and only then pass it to the LLM. Your agent gets clean, relevant context and guardrails embedded in the tools. You get better results at a fraction of the cost.
Time is not an agent problem #
Agents are not good at measuring time — and they’re not supposed to be. Scheduling, enforcing run-time limits, triggering tasks at a given hour: these are deterministic operations. A script or a cron job handles them precisely. An agent will approximate and occasionally hallucinate.
If you want an agent to act as a personal assistant and manage your calendar, give it a script that calculates start and end times. Let the agent decide what to schedule. Let the script determine when.
Let agents write SQL. Don’t let them run it. #
Agents are genuinely impressive at writing SQL. They read your codebase, find the relevant tables, understand the schema, and produce in seconds what might take you hours. It won’t always be perfect — but that’s a different conversation.
The risk is access, not quality. If you give an agent direct write access to your database, you are one hallucination away from a DROP statement. It has already happened.
The fix is simple: build a script that sits between the agent and the database. It checks the SQL before execution — does it contain a DROP? A TRUNCATE? — and runs the query through a controlled interface. The agent writes. The script decides whether to run.
LLM only, or agent? #
The distinction is simpler than it looks. Use a single LLM call when the task is self-contained: summarization, intent extraction, classification, tone adjustment. The input goes in, the output comes out, no further steps needed. Use an agent when the task requires reasoning across multiple steps, or when it needs to use tools — including the scripts you’ve already built. The agent becomes the orchestrator; the scripts become its instruments.
A practical example makes this concrete. Say you want to triage every open ticket in your organization and prioritize the work that needs to be done. If you rely entirely on an agent, it will use MCP tools to extract Jira data, load it all into context, and process the full text. The problem is that ticket extraction is a deterministic operation — it’s an API call, or a database query. Using an agent for it expands the context window unnecessarily, increases the probability of hallucinations, and burns tokens on work that requires no judgment. The better design: a script extracts and structures the ticket data, and the agent receives clean input to reason about priority, assign work, and write back.
Contrast that with a different question: what are the main complaints your customers mention in support tickets, and how do they feel? That’s a single, self-contained reasoning task. No tools needed. A direct LLM call is not just sufficient — it’s the right choice.
The broader principle: complex agentic systems solve reasoning problems. They are not shortcuts for problems that aren’t reasoning problems to begin with. Over-engineering in this direction doesn’t simplify your system — it adds orchestration overhead, multiplies failure points, and increases the surface area for hallucinations. Good engineering is knowing when not to reach for the most powerful tool available.
Conclusion #
The goal is not to avoid agents. It’s to use them precisely.
Giving your agent the right tools — scripts that handle deterministic work, structured inputs that reduce noise — means you’re not asking it to figure out what it should already be given. The result: you build faster, spend less on tokens and compute, and give the LLM less room to hallucinate.
The line between what an agent should reason about and what a script should simply execute is learnable. Drawing it well is, right now, a meaningful competitive advantage.
In the next post, I’ll cover the NLP toolkit that makes this pipeline possible — the lightweight techniques every data practitioner should know before reaching for an LLM.