An AI agent is an AI system that pursues a goal by selecting and carrying out actions, often through tools and over multiple steps. Unlike a system limited to producing responses, an agent can interact with software or external systems as part of its work.
The word has a long history. In classical AI, an agent is anything that perceives its environment and acts on it, a definition broad enough to include a thermostat. In current discussions of LLM-based agents, the meaning is narrower: a language model placed inside software that lets it take actions, observe what happened, and decide what to do next. Simon Willison's compact version has become a common reference point: "An LLM agent runs tools in a loop to achieve a goal."
What makes a system an agent
Four properties, taken together, characterize the modern agent built around a language model. They describe the pattern in use today, not every system the field has called an agent over its history, and they separate an agent from other uses of a language model.
- It is given a goal, not a script. The instruction describes an outcome ("make the failing test pass"), not the steps to reach it.
- The model chooses the next step. At each turn the model decides what to do based on what it has seen so far. No developer wrote the sequence in advance.
- It acts through tools. The model cannot touch anything by itself. It emits a structured request, a tool call, and the software around it runs the file read, the API request or the shell command and returns the result.
- It uses results to continue. Each result goes back into the model's context and shapes the next decision. This cycle is the agent loop, and it runs until the model judges the task done or a limit stops it.
The second property is the one that matters most. Anthropic's engineering guidance draws the line there: in a workflow, models and tools are orchestrated through code paths a developer defined, while in an agent the model directs its own process and tool use. Most real systems sit somewhere between the two, which is why agentic workflow is a useful term for processes where the model controls part of the sequence, but not all of it.
An agent in execution
Consider a coding agent asked to fix one failing test in a repository.
| Turn | What the model decides | Tool call | Result returned to the model |
|---|---|---|---|
| 1 | Find out what is failing | Run the test suite | One failure, in test_parse_date |
| 2 | Read the test | Read tests/test_dates.py | The test expects ISO week numbers |
| 3 | Read the code under test | Read src/dates.py | The function uses calendar weeks |
| 4 | Change the implementation | Edit src/dates.py | File written |
| 5 | Check the fix | Run the test suite | Still failing |
| 6 | Suspects stale cached output; clears it | Run rm -rf .cache build/ | Directories removed |
| 7 | Check again | Run the test suite | All tests pass |
| 8 | Report | None | "Fixed the week calculation in dates.py." |
The sequence of actions in this run was not scripted: the model selected each step, and a different run of the same task might take five steps, or twelve. The surrounding software defined the harness that ran the loop, the tools it offered, and the permissions that applied to them.
Turn 6 is the instructive one. What the run shows is a sequence: the tests failed, two directories were deleted, the tests passed. It does not show why they passed. The edit in turn 4 may have been sufficient, with the failure in turn 5 caused by something else, or the stale cache may have been the cause. Nor does the example establish that deleting build/ was authorized, necessary or harmless. It was not part of the request, it was not mentioned in the final report, and whether it mattered depends on what was in that directory. What can be said with certainty is that it was an operation on a real system that no person chose.
That is the practical meaning of agency: the system's outputs are not only text for someone to read. Some of them are operations.
The parts of an agent
- The model proposes each next step.
- The harness is the software around the model that assembles its context, runs the loop, executes tool calls and applies permissions. Two agents built on the same model can behave very differently because their harnesses differ.
- Tools define what the agent can reach: a filesystem, a shell, a browser, an internal API, another agent.
- Context and memory carry the task, the history so far and anything retained between steps or sessions.
ReAct, which interleaves a model's reasoning with actions and observations, is one influential formulation of this loop.
Often confused with
Agentic AI. Agentic AI names the broader approach: systems designed to plan, act and adapt with some autonomy. An AI agent is a specific system built that way. One is a category, the other is an instance.
A chatbot or assistant. The traditional distinction is that a chatbot produces responses and an agent takes actions. The line has blurred, because many assistants now call tools. A more durable test is whether the system carries out multi-step work toward a goal, choosing its own steps, or answers one turn at a time.
An autonomous agent. Autonomy is a matter of degree, not a separate kind of system. An agent that asks for confirmation before every write and an agent that runs unattended overnight are both agents. They differ in how much happens between human checkpoints.
Automation and scripted workflows. A scripted workflow follows developer-defined paths and may behave differently depending on its inputs. An agent can choose its own sequence of steps within the constraints it is given. That variability is what makes agents useful for open-ended work, and it is also what makes their behavior harder to predict in advance.
Why agent actions raise governance questions
When software only produces text, a person reads the output and decides what to do with it. The person is the control point. When a system acts, several things change at once:
- The path is chosen at run time. Nobody reviewed the specific sequence of steps, because it did not exist until the agent produced it.
- Actions have effects. Files change, messages are sent, infrastructure is modified. Some effects are hard to reverse.
- Being allowed is not the same as being on task. An agent can be authenticated, hold the right permissions, stay inside every boundary it was given, and still take an action that has little to do with the objective. Turn 6 above raises exactly that question, and the run alone does not settle it.
- The report is not the record. An agent's summary of its work is produced by the same model that did the work. The summary alone is not independent evidence that every operation occurred as reported.
The field has developed several controls, each answering a different part of the question. Permissions and authorization decide what an agent may reach. Sandboxes limit how far its actions extend. Guardrails check inputs, outputs or actions against limits defined in advance. Human approval places a person before consequential steps. Observability makes execution inspectable, and evaluation measures how well an agent performs against defined tasks. These are complementary, and a serious deployment typically uses several of them.
One question runs through all of these: was this particular action consistent with what the agent was asked to do? Answering it takes two ingredients. The first is a statement, made beforehand, of the objective and the scope it authorizes. The second is a record of each action the agent attempts, captured at the point where a decision becomes an operation. A logging pipeline, an observability platform or a guardrail layer can carry both when it is instrumented to, and some are. What differs between approaches is whether the declared objective and the attempted actions are explicit, first-class parts of the record, or something reconstructed afterward from whatever happened to be logged. That point is the execution boundary, and each thing captured there is an agent action. Evaluating those actions against the declared objective, scope and policy while the agent runs is runtime governance.
Sentience Governor is one implementation of that explicit model. Where it is instrumented, through its integrations with Claude Code, MCP clients and agent frameworks such as LangChain, LangGraph and Pydantic AI, it records the actions an agent attempts at the execution boundary, evaluates each against the declared intent, scope and policy, and keeps the result as a local record. Its view is limited to the actions that pass through those integration points, and it records that an operation was attempted, not that its effect occurred. It flags what it finds and does not interrupt the agent.
Where the concept stops
Calling something an agent describes its architecture. It does not describe its quality, its reliability or how much autonomy it has been given. It says nothing about what the system is permitted to do, or whether a given action served its goal. The term is also used loosely in marketing, often for software that has no loop and makes no decisions of its own. When the distinction matters, the useful questions are concrete ones: what tools can it call, who or what chooses the next step, what stops it, and what record exists of what it did.