Half the "AI agent" market in 2026 is mislabeled. Before we argue about where to run them, we need to agree on what they are, what makes something an agent vs. a one-shot tool, and why narrow agents almost always beat one giant brain.
- An agent in one sentence
- Proxy vs. agent, the feedback loop is the whole point
- Things people call "agents" that aren't
- Big brain or swarm of bees?
- Why this distinction decides everything that follows
An agent in one sentence
An AI agent is a piece of software that uses a language model to decide what action to take next, based on what it just saw. That's the whole thing.
Two ingredients matter:
- Decide. It picks the next step, not a human, not a hard-coded flowchart.
- Based on what it just saw. It observes the result of its last action and adapts. State + adaptation.
Strip either one out and you have something else. A static workflow with an LLM call in the middle isn't an agent, the workflow decided, the model just filled in a blank. A chatbot that answers one question and forgets isn't an agent, there's no "next step" being chosen. Both useful. Neither agentic.
Proxy vs. agent, the feedback loop is the whole point
Most software you've ever written is a proxy: a function that does this:
input → process → output → done.Useful. A spam filter. A summarization endpoint. A classification model. An autocomplete. But fundamentally a function, same input, same output, no memory, no retry, no adaptation.
An agent does this:
input → act → observe → decide → act again → … → done.The loop is the whole point. The agent takes an action, sees what came back, updates its understanding, picks the next action. It might call ten tools to answer one question. It might retry when something fails. It might decide the task is done, or that it needs more information first.
A concrete example. Ask a proxy: "What's the weather in Vilnius?" → it calls a weather API → returns the answer. Done. Ask an agent: "Book me a flight to Vilnius for next Friday under €200, window seat, morning if possible." → it searches flights → none match → it broadens the search → checks adjacent airports → finds a match → checks if I have miles to upgrade → asks me if I want to confirm. Different work. Different mental model.
Proxy: one question, one answer. Agent: one goal, many tools, until done.
Things people call "agents" in 2026 that aren't
Vendor marketing is loose. Useful to filter before any deployment conversation. Two questions to cut through marketing:
- "Can it decide to call a different tool than I expected?" If no → proxy or workflow.
- "Can it retry, branch, or stop on its own?" If no → proxy or workflow.
Both yes? Agent. One or both no? Useful tool, not an agent. That distinction is what makes the rest of this series matter, proxies are cheap and bounded, agents are loud and consequential.
Big brain or swarm of bees?
One more myth to break. Vendors love selling "the smartest model for your agent." Most agent tasks don't need the smartest model. They need the right-sized model for the specific job.
NVIDIA Research made the case in mid-2025: most agent tasks don't need a frontier model at all. An agent that classifies inbound emails, extracts fields from invoices, formats a CRM update, or decides which of three tools to call is using maybe 5% of what GPT-5.5 can do. A 3B-parameter model fine-tuned for that narrow job will match or beat the frontier model, and run on a Raspberry Pi.
Think of bees. A honeybee has roughly a million neurons. It's bad at chess, bad at calculus, and incapable of writing a sonnet. It's also extraordinarily good at the one job it has: navigate, pollinate, return. A hive of 50,000 specialized bees outperforms one giant generalist creature on every metric that matters to the colony, throughput, resilience, cost per unit of work.
Same shape applies to agent systems. A swarm of small specialized agents, one to detect intent, one to call the API, one to format the reply, one to log the result, is faster, cheaper, more debuggable, and more local-friendly than one giant prompt to a frontier model. The frontier model becomes the "queen", called only when the cheap workers genuinely need her judgment.
A swarm of bees doesn't need a brain the size of a basketball. Neither does most of what your agents actually do.
Why this distinction decides everything that follows
The rest of this series argues about where agents should run, security, performance, cost, IP reputation, regulation. None of that argument lands if you're talking about something that isn't actually an agent.
Three concrete reasons the agent / proxy line matters for deployment:
- Volume. A proxy fires once per request. An agent fires until the task is done, that can be 5 tool calls or 100. Cloud rate limits, IP reputation thresholds, ISP fair-use caps all compound differently for loops vs. one-shots.
- Side effects. Proxies usually read. Agents write, they send emails, file tickets, transfer money. The cost of "wrong" is asymmetric. That changes the security and audit story completely.
- Failure mode. A proxy fails by returning a bad answer. An agent fails by running in a confused loop until you stop it, or until your budget alarm does. Where you put it, and what guardrails surround it, decide whether it can do that.
If you only take one thing from this part: "agent" means observe-and-adapt loop with side effects. Anything else is a proxy. The deployment question is interesting because of the loop, without it, "where it runs" is just hosting trivia.
