In 30 seconds
An AI agent is a system that can use a model to decide what step to take next and interact with defined tools, within limits you set. The important thing about an agent is not that it feels autonomous. It is what it is allowed to read, decide and change.
The simple model
A chatbot answers. An agent can also act. Given a goal, it can use model output to choose between allowed steps, call tools, and work toward the goal across several steps.
For example, a chatbot might tell you a customer needs a new appointment. An agent could also check the calendar, find an allowed slot and prepare the booking. The difference is the move from producing information to choosing and performing actions.
Why the word "autonomous" is misleading
Agents are often described as autonomous or as thinking for themselves. That framing hides the part that actually matters for design.
An agent does not have judgment or responsibility. It follows a goal using the tools and permissions you give it. So the useful questions are not philosophical. They are concrete:
- What can it read?
- What can it decide?
- What can it change, and what needs approval first?
Answer those, and "how autonomous is it" mostly answers itself. See automation vs AI vs agent.
Authority, not intelligence, is the design surface
Because an agent can act, the design work is mostly about authority and boundaries:
- Which systems and data it can read versus write.
- Which actions it may suggest, draft or execute.
- What happens when it is unsure or something fails.
An agent with narrow, well-defined authority is safer and more useful than a clever one with vague permissions.
A small example
A support agent was described as "autonomous", which worried everyone. Reframing it by authority calmed the discussion: it could read tickets and the knowledge base, decide a category and a draft reply, and could not change any customer record or send anything without a person. Defined that way, it was clearly safe to try.
What this does not solve
Calling something an agent, or not, does not make it safe. Safety comes from explicit permissions, tested boundaries, failure handling, logging and an owner. The label is a starting point for that work, not a substitute for it.
