A plain-language guide to classifying AI agents by scope of work and autonomy, from chat wrappers to autonomous agents that hold a job, with definitions of harness, model, context, memory, skills, and routines.
An AI agent is just software.
It consists of a software application called a “harness” and a large language model (LLM). The harness facilitates words in and out of the model: it sends words in, and gets words out as a response, one chunk at a time.
The harness also takes care of intaking the desired goal from a human and shuttling back the results of its work. And in the course of doing the work, it (might) send data out to the world and pull data back in.
This sounds magical, but really the only difference between this and any other software is the interaction with the LLM. That interaction is special, because it’s non-deterministic: the same words in to the model will not produce the same words out – even with the same model. And there are loads of models to choose from, depending on which kinds of words (code, prose, marketing copy, search results) you want back.
The words that go back and forth from the model are mostly referred to as tokens.
Kinds of agents
When we talk about kinds of agents, we’re mostly talking about their harness. Some harnesses are merely thin wrappers on the model, like ChatGPT, directly passing the words you say or type to the model, and sending its response right back to you.
On the other hand, a harness can be very sophisticated, orchestrating parallel streams back and forth with the model on its own, and weaving in information from across other systems and agents.
But all of these things fall under the umbrella of what we call AI agents, even though our interactions can vary widely from harness to harness. So we need a way to categorize them.
You can think of AI agents as working across two dimensions: scope of work and autonomy.
Sometimes the scope of work is a single task, like fetching a recipe or writing some code. But the scope can get much bigger: an agent might have a job – a collection of recurring routines and tasks – like a human would. For example, a marketing research assistant that monitors campaigns, surfaces trends, and even creates new ones.
The level of autonomy is the other dimension. Autonomy is very low for an agent like ChatGPT. Its work is done and delivered on demand, incrementally, on your desktop or phone, usually through one-on-one chat sessions. On the other end of the spectrum, some agents are running in the background, on servers in data centers, working through routines and tasks without any human intervention at all.
Single-player and multiplayer
We hear a lot about “single-player” agents and “multiplayer” agents. Single-player agents are tied to a single person’s session, like ChatGPT or Claude Cowork. A person provides a scope of work and gets back a result. Usually the harness is running on that person’s computer.
Multiplayer agents are not tied to a user session. They perform work on behalf of a team or an organization of humans (and maybe other agents). The harness is often running on networked servers somewhere. More often than not, multiplayer agents are more autonomous.
Memory and context
An LLM does not carry history around inside itself. Each time the harness sends words to the model, it assembles a temporary working set of instructions and information called the context. That might include earlier messages, relevant files, search results, and a description of what the agent is allowed to do. The model can only “reason” (or work to return words) from what the harness puts into that context. In other words, context is made up of the words that are prepended to the task-specific words sent to the model.
Memory is information the harness preserves so it can be used in a future context. It might be a conversation transcript, a database record, a summary, or an ordinary file. When people say an agent “learned” something, they often just mean the harness saved information and retrieved it later; the model itself was not retrained (that’s another topic).
Skills and routines
Skills are reusable instructions for how to do a particular kind of work. A skill might explain how to summarize an article, investigate a bug, or prepare a weekly report. Most skills are largely words: prompts, examples, checklists, and rules that the harness adds to the model’s context when needed. But a skill can also include scripts, templates, or other tools that the harness runs in conjunction with sending words back and forth to the model.
Routines describe work that should happen repeatedly or in response to an event. A routine combines a trigger – every morning, when an issue is opened, when a metric changes – with a goal and the skills and tools needed to pursue it. The harness wakes the agent, assembles the right context, lets it do the work, records what happened, and delivers the result.
Skills say how to do work; routines say when to do it.
Portability
The harness and the model are separate parts of an agent, but they are not always interchangeable. Some harnesses are built for one model or one model provider. Others can work with many models, allowing the person running the agent to choose among them or switch models for different kinds of work.
Even when a harness supports several models, they may not work equally well. Models differ in how they follow instructions, manage long contexts, write code, and communicate their reasoning back to the harness. A harness may also rely on features that only certain models provide. So model portability is a spectrum: some agents are tightly coupled to one model, while others can choose the best model for each task.
Security and privacy
There are two boundaries to protect. The first is the harness’s connection to the world: what information can enter, what systems it can read or change, and which credentials and tools it can use. Untrusted email, webpages, documents, and messages can contain instructions intended to manipulate the agent. And an agent with broad permissions can make broad mistakes.
The second boundary is between the harness and the model. Anything placed in the model’s context may be sent to a model provider (if it’s a third party; people and companies are also running their own local models now), retained under that provider’s policies, or exposed through logs and traces.
From a security and privacy perspective, agents should be treated like any other deployed software. (Because that’s what it is!) Give it only the access it needs, isolate its work where practical, and require approval for consequential actions. And secrets and private data should be filtered before they become tokens, not merely hidden from the human-facing result.
Orchestration, governance, and coordination
These three ideas are often conflated, but they solve different problems. Orchestration is how the machinery runs: starting agents, routing work, sequencing steps, calling tools, handling failures, and deploying the harness. Governance sets and enforces the boundaries: who authorized the work, what the agent may access, which actions require approval, and how its behavior can be inspected and audited.
Coordination is how the work of agents and humans fits together. It establishes shared goals, ownership, dependencies, handoffs, progress, and blockers so that independently completed tasks add up to a useful outcome.
Orchestration can keep an agent busy and governance can keep it within bounds, but coordination is what makes its work contribute economic value.
It’s just software automation
Agents feel different from ordinary automation because they communicate in language, appear to make judgments, and sometimes behave unpredictably. Humans have been inclined to project understanding onto conversational software since ELIZA in the 1960s.
Today’s systems are vastly more capable, but the same instinct can make their output seem more intentional (or credible) than it actually is.
An agent is still just deployed software. It has inputs, outputs, dependencies, permissions, failure modes, operating costs, and people responsible for it. Treating an agent like software does not diminish what it can do; it just gives us a practical way to make it useful.
Define its job, limit its access, test its behavior, observe its work, and improve it when it fails.