"Agent" is currently the most overloaded word in software. A chatbot with a system prompt gets called an agent. A Zapier flow with an LLM step gets called an agent. A cron job that drafts emails gets called an agent. The inflation matters, because what you call a thing decides how carefully you deploy it, and real agents deserve far more care than chatbots.
So before arguing about agent security, it's worth pinning down what an agent actually is. The good news: the people who have thought hardest about this largely agree.
Bill Gates describes agents in terms of behavior: they act proactively rather than waiting for the next instruction, they work across applications instead of living inside one, and they improve as they learn about you. a16z draws the line at capability: an agent plans multi-step sequences toward a goal and interacts with outside systems. It calls APIs, reads data, and executes rather than just generating text. Sequoia frames it operationally: you dispatch an agent with a goal rather than steps, it recovers when something fails instead of giving up, and it persists until the job is done.
João Moura, the founder of CrewAI, gives the most builder-shaped version: an autonomous unit that scans its environment, uses tools to accomplish objectives, maintains memory of its interactions, makes decisions based on its role and goal, communicates and delegates, and adapts from feedback.
Diagram: Where the definitions converge.
- Bill Gates (proactive · cross-app · learns)
- a16z (plans · touches real systems)
- Sequoia (goal-dispatched · persistent)
- João Moura (scan · tools · memory · delegate)
- The consensus (plans · acts · adapts on its own)
- Bill Gates to The consensus
- a16z to The consensus
- Sequoia to The consensus
- João Moura to The consensus
If every step was decided before the run, you have a workflow. If the system decides the next step at runtime, and answers for the outcome, you have an agent.
- A chatbot, even a brilliant one. It can reason through a problem and write the code to solve it, but it executes nothing itself. Text in, text out.
- A custom GPT. You described what it should do; it generates responses shaped by that description. Configuration is not autonomy.
- An LLM step inside an automation. Email arrives, model summarizes, automation files a ticket. Useful, but the path is fixed. It cannot decide to escalate instead, refund instead, or do nothing.
This is why n8n, Zapier, and Make call their products workflows even when an LLM sits in the middle of the canvas. Branches don't change the verdict: an IF node with three paths is still you supplying the steps, just all of them ahead of time. At runtime the graph decides where execution goes; the model only fills in content along the way. And n8n's AI Agent node proves the rule instead of breaking it. Inside that one node the model picks which tool to call next, so n8n gives it a different name. The boundary of the drawn graph is the boundary of the workflow; autonomy begins where the drawing stops.
None of these are lesser tools. They are safer tools, precisely because they cannot choose their own actions. The moment a system picks its next move, it crosses into agent territory, and into a different risk class.
Stack the four definitions and a single loop falls out: six capabilities that separate an agent from everything else. Moura's definition names the zones most cleanly; here is that loop as I think about it when I'm deciding whether something is actually an agent.
Diagram: The agent loop.
- Perception (scan environment)
- Memory (retain interactions)
- Reasoning (plan by role + goal)
- Action (tools · apis · code)
- Feedback (observe + adapt)
- Collaboration (delegate + hand off)
- Perception to Memory
- Memory to Reasoning
- Reasoning act to Action
- Action to Feedback
- Feedback to Collaboration
- Collaboration to Perception
- Feedback adapt to Reasoning
Here is the part the definitions leave out, and the reason the distinction is worth defending: each capability that makes a system an agent is also a place where it can be attacked. The loop reads as a feature list to a builder and as a target list to an adversary.
- Perception ingests untrusted content, which makes it the delivery channel for injection.
- Memory makes planted data persistent: poison it once and it shapes decisions long after the session that ingested it.
- Reasoning is where a poisoned input becomes a bad plan that looks deliberate.
- Action is the blast radius. Everything before it is text; this is where text becomes an API call, a write, an email.
- Feedback can be gamed: an attacker who controls what the agent observes controls what it learns.
- Collaboration multiplies all of the above across every agent that trusts this one's handoffs.
A concrete version: picture an on-call agent that watches alerts, correlates them with recent deploys, rolls back the likely culprit, and pages a human only when it's unsure. That is a real agent: it perceives, remembers past incidents, plans, acts, and adapts. It is also a system where a forged alert can trigger a rollback, and a poisoned runbook can teach it the wrong fix. Same loop, both readings.
Diagram: An agent on call.
- Alert fires (monitoring webhook)
- On-call agent (correlate + plan)
- Incident memory (past fixes · runbooks)
- Root cause (confident?)
- Roll back deploy (scoped credentials)
- Page a human
- Alert fires trigger to On-call agent
- Incident memory recall to On-call agent
- On-call agent to Root cause
- Root cause yes to Roll back deploy
- Root cause unsure to Page a human
- Roll back deploy outcome to On-call agent
So the test is simple: does the system decide its own next step? If not, call it what it is, a workflow, and enjoy the safety that comes with fixed paths. If it does, you have an agent, and the six zones above are the checklist for what it can do and for what something else can convince it to do. Bound the loop, especially the action zone, and you get the upside without handing your credentials to whoever can reach its inputs.
