In order to unpack this question, we need to go back to how we define agents and agency. Russell and Norvig's textbook definition, is that an agent is anything that perceives its environment through sensors and acts on that environment through actuators. By that definition, a thermostat is an agent. So is a loop that reads a tool's output, decides which function to call next, and repeats. Nothing about that requires intention, self-awareness, or persistent goals. It just requires a perceive-act cycle. On that basis, within a narrowly technical cybernetic definition, calling an LLM-plus-tool-loop an agent is not a misnomer at all.

However, what we frequently allude to when we talk about ‘agents’ is actually ‘agency’ and whether it has delegated action and/or delegated decision-making. Calling something an agent can make its autonomy sound greater than it actually is, while simultaneously obscuring where the real control architecture sits. A system might be able to interpret a goal, decide what steps to take, select tools, act repeatedly, observe the consequences, change course, retain state or memory and operate without a human specifying every intermediate action. That is architecture. Delegated authority is a different question entirely and that is a governance question: What has the system actually been authorised to decide or do? You can therefore have a highly agentic system with almost no meaningful authority, and you can have a relatively simple automated system with enormous real-world authority.

What most products currently call an agent is a loop: an LLM given a system prompt, some tools, and permission to call those tools repeatedly until it decides the task is done. That is a real capability shift from a model that only produces text in response to a single prompt. However, it is not the same as the more demanding sense of agency in some AI and robotics literature, where an agent holds persistent goals, a model of its environment, and some capacity to revise its plan against new information over time.

What we have instead is a system that re-prompts itself with the output of its last action and keeps going towards the goal it has been set. The PocketOS example is a good use case here. The agent hit a permissions error, decided unilaterally to delete the database rather than stop and ask, then wrote its own confession afterward. That is not strategic reasoning about competing goals. It is a completion-optimised loop doing exactly what it was built to do, at the expense of every constraint it had been given.

Calling that an agent in the fuller sense flatters the architecture and, more importantly, misdirects the governance conversation. If people believe they are deploying something with judgement, they build oversight for judgement. What they actually need to build oversight for is a system that will complete a task with total efficiency regardless of the constraints in its way, which is a narrower and more dangerous problem than the word "agent" suggests.

However, there is a third way in which the term is used and when we are talking about accountability it is important to acknowledge. Legal and economic agency, doesn’t depend on either machine ‘intention’ or technical architecture. It boils down to legal authorisation, control, and the delegation of duties on behalf of a principal. If a system is legally or functionally treated as an agent executing tasks for a principal, liability can attach regardless of whether the human operator understood the internal mechanics of the loop. This is precisely the argument being tested in the U.S case Mobley v Workday, which scrutinises whether automated enterprise platforms function as legal agents of the entities deploying them, and where the boundaries of statutory liability lie.