In software engineering, the principle of parsimony (Occam’s Razor) is vital: do not use a complex solution when a simpler one suffices. Agents are powerful but introduce stochasticity (unpredictability) and high compute costs.
As a seasoned engineer, you must evaluate where your problem falls on the spectrum of complexity.
The Hierarchy of AI Solutions
1. Non-AI (Deterministic)
If the logic can be expressed in a flowchart, don’t use AI. * Example: Calculating the correlation between two input parameters. * Solution: Use a statistical test like \(\chi^2\) (Chi-squared). It is 100% reliable, near-zero cost, and takes microseconds.
2. Traditional ML (Discriminative)
If you need to classify data or predict a value based on patterns, but don’t need “reasoning.” * Example: Sentiment analysis on customer reviews. * Solution: Use a BERT-based model or even classical NLP. It’s faster, cheaper, and often more accurate for specific classification tasks than a general-purpose LLM.
3. Simple LLM Call (Generative)
If you need to transform text or summarize information in a single pass. * Example: Hawkwatch — Using an LLM to extract specific data points from a document. * Solution: A single completion call. No loop or tools required.
4. RAG (Retrieval-Augmented Generation)
If the LLM needs specific external knowledge to answer a question, but the process is still “one-shot.” * Example: Hearti — A health assistant that uses VespaAI to retrieve medical facts before answering. * Solution: Retrieve context -> Inject into prompt -> Generate response.
5. Workflow (Chained Logic)
If the task has multiple steps that follow a predictable, but complex, branching path. * Example: Workflow AI — An automated pipeline for processing data. * Solution: Use a directed acyclic graph (DAG) where each node is an LLM call or a function. The path is pre-defined by the developer.
6. Agentic AI (Dynamic Logic)
If the task is open-ended, the path to the solution is unknown at runtime, or the system needs to interact with an environment and adapt based on feedback. * Example: AgentZero or WiiWork. * Solution: A ReAct loop where the agent decides which steps to take based on the results of previous steps.
The Essence of “Agentic” Tasks
The core argument for using an agent boils down to Uncertainty and Environment Interaction.
1. The Path is Not Pre-Defined
In a Workflow, the developer is the architect: “First do A, then if B happens, do C.” In an Agent, the developer is the environment designer: “Here are tools A, B, and C. Figure out how to reach goal G.” If you can’t predict the sequence of steps a human would take to solve the problem, you need an agent.
2. Adaptive Problem Solving
Agents excel when the “Observation” (the result of a tool call) fundamentally changes the next “Thought.” * Non-Agentic: “Search for flights and email me the list.” (Linear) * Agentic: “Book me a flight. If the price is over $500, check if there’s a train. If the train takes more than 5 hours, find a hotel for a layover and ask me for approval.” (Dynamic)
3. The “Last Mile” of API Integration
Agents are the ultimate “glue” code. They can handle the messy reality of inconsistent APIs, semi-structured data, and unexpected errors by “reasoning” their way through a failure rather than just throwing an exception.
The Engineer’s Heuristic:
If you can draw a flowchart for it, build a Workflow. If the flowchart would be infinite or recursive, build an Agent.