AI Agents
Software that uses an LLM to decide what to do next, calls tools to act on those decisions, and loops until a goal is reached.
An AI agent is the loop, not the model. The model (Claude, GPT, Gemini, an open-weights LLM) is the decision-maker. The agent is the runtime: it gives the model a goal, lets it call tools (a database, an API, a code interpreter, another agent) often via MCP, observes the result, and feeds the loop until done.
The distinction matters because agentic systems fail differently from straight LLM applications. A chatbot can be wrong and the user moves on. An agent that is wrong sends an email, makes a transaction, or deletes a file. Production agents need authorisation gates, observability, and circuit breakers that most prototypes skip.
Worked example of the most common production failure: a support agent is given a “resolve ticket” goal and a set of tools. A malformed ticket sends it into a loop where it calls the same lookup tool dozens of times, burns through the model budget in an afternoon, and never reaches a resolution. The fix is not a smarter prompt, it is engineering: a hard step limit, a cost ceiling, and a circuit breaker that halts the loop and escalates to a human. Anything that writes (sends a message, makes a payment, deletes a record) gets a human-in-the-loop gate; read-only loops can usually run unattended.
The honest trade-off and the founder mistake to avoid: agents add non-determinism, latency, and a much larger blast radius than a fixed pipeline, in exchange for handling tasks whose steps cannot be enumerated in advance. Most workflows pitched as “agentic” are well-understood and are better served by a deterministic pipeline with one or two LLM calls in the middle, often backed by RAG for grounding. Wavect’s posture: start by asking if AI is the right tool here, then whether an agent is the right shape of AI for it. If you can write the steps down, do not let the model improvise them.